前言
到了年底果然都不太平，最近又收到了运维报警：表示有些服务器负载非常高，让我们定位问题。
果然某些线程的 CPU 使用率非常高。
为了方便定位问题我立马使用 jstack pid > pid.log 将线程栈 dump 到日志文件中。
我在上面 100% 的线程中随机选了一个 pid=194283 转换为 16 进制（2f6eb）后在线程快照中查询：
因为线程快照中线程 ID 都是16进制存放。
发现这是 Disruptor 的一个堆栈，前段时间正好解决过一个由于 Disruptor 队列引起的一次
其中有一项菜单展示了所有消耗 CPU 的线程，我仔细看了下发现几乎都是和上面的堆栈一样。
也就是说都是 Disruptor 队列的堆栈，同时都在执行 java.lang.Thread.yield 函数。
众所周知 yield 函数会让当前线程让出 CPU 资源，再让其他线程来竞争。
根据刚才的线程快照发现处于 RUNNABLE 状态并且都在执行 yield 函数的线程大概有 30几个。
因此初步判断为大量线程执行 yield 函数之后互相竞争导致 CPU 使用率增高，而通过对堆栈发现是和使用 Disruptor 有关。
到了年底果然都不太平，最近又收到了运维报警：表示有些服务器负载非常高，让我们定位问题。
果然某些线程的 CPU 使用率非常高。
为了方便定位问题我立马使用 jstack pid > pid.log 将线程栈 dump 到日志文件中。
我在上面 100% 的线程中随机选了一个 pid=194283 转换为 16 进制（2f6eb）后在线程快照中查询：
因为线程快照中线程 ID 都是16进制存放。
发现这是 Disruptor 的一个堆栈，前段时间正好解决过一个由于 Disruptor 队列引起的一次
其中有一项菜单展示了所有消耗 CPU 的线程，我仔细看了下发现几乎都是和上面的堆栈一样。
也就是说都是 Disruptor 队列的堆栈，同时都在执行 java.lang.Thread.yield 函数。
众所周知 yield 函数会让当前线程让出 CPU 资源，再让其他线程来竞争。
根据刚才的线程快照发现处于 RUNNABLE 状态并且都在执行 yield 函数的线程大概有 30几个。
因此初步判断为大量线程执行 yield 函数之后互相竞争导致 CPU 使用率增高，而通过对堆栈发现是和使用 Disruptor 有关。
