摘要：發(fā)現(xiàn)這是的一個堆棧，前段時間正好解決過一個由于隊列引起的一次強(qiáng)如也發(fā)生內(nèi)存溢出沒想到又來一出。因此初步判斷為大量線程執(zhí)行函數(shù)之后互相競爭導(dǎo)致使用率增高，而通過對堆棧發(fā)現(xiàn)是和使用有關(guān)。

到了年底果然都不太平，最近又收到了運維報警：表示有些服務(wù)器負(fù)載非常高，讓我們定位問題。

還真是想什么來什么，前些天還故意把某些服務(wù)器的負(fù)載提高（沒錯，老板讓我寫個 BUG！），不過還好是不同的環(huán)境互相沒有影響。

拿到問題后首先去服務(wù)器上看了看，發(fā)現(xiàn)運行的只有我們的 Java 應(yīng)用。于是先用 ps 命令拿到了應(yīng)用的 PID。

接著使用 top -Hp pid 將這個進(jìn)程的線程顯示出來。輸入大寫的 P 可以將線程按照 CPU 使用比例排序，于是得到以下結(jié)果。

果然某些線程的 CPU 使用率非常高。

為了方便定位問題我立馬使用 jstack pid > pid.log 將線程棧 dump 到日志文件中。

我在上面 100% 的線程中隨機(jī)選了一個 pid=194283 轉(zhuǎn)換為 16 進(jìn)制（2f6eb）后在線程快照中查詢：

因為線程快照中線程 ID 都是16進(jìn)制存放。

發(fā)現(xiàn)這是 Disruptor 的一個堆棧，前段時間正好解決過一個由于 Disruptor 隊列引起的一次 [OOM]()：強(qiáng)如 Disruptor 也發(fā)生內(nèi)存溢出？

沒想到又來一出。

為了更加直觀的查看線程的狀態(tài)信息，我將快照信息上傳到專門分析的平臺上。

http://fastthread.io/

其中有一項菜單展示了所有消耗 CPU 的線程，我仔細(xì)看了下發(fā)現(xiàn)幾乎都是和上面的堆棧一樣。

也就是說都是 Disruptor 隊列的堆棧，同時都在執(zhí)行 java.lang.Thread.yield 函數(shù)。

眾所周知 yield 函數(shù)會讓當(dāng)前線程讓出 CPU 資源，再讓其他線程來競爭。

根據(jù)剛才的線程快照發(fā)現(xiàn)處于 RUNNABLE 狀態(tài)并且都在執(zhí)行 yield 函數(shù)的線程大概有 30幾個。

因此初步判斷為大量線程執(zhí)行 yield 函數(shù)之后互相競爭導(dǎo)致 CPU 使用率增高，而通過對堆棧發(fā)現(xiàn)是和使用 Disruptor 有關(guān)。

而后我查看了代碼，發(fā)現(xiàn)是根據(jù)每一個業(yè)務(wù)場景在內(nèi)部都會使用 2 個 Disruptor 隊列來解耦。

假設(shè)現(xiàn)在有 7 個業(yè)務(wù)類型，那就等于是創(chuàng)建 2*7=14 個 Disruptor 隊列，同時每個隊列有一個消費者，也就是總共有 14 個消費者（生產(chǎn)環(huán)境更多）。

同時發(fā)現(xiàn)配置的消費等待策略為 YieldingWaitStrategy 這種等待策略確實會執(zhí)行 yield 來讓出 CPU。

代碼如下：

初步看來和這個等待策略有很大的關(guān)系。

為了驗證，我在本地創(chuàng)建了 15 個 Disruptor 隊列同時結(jié)合監(jiān)控觀察 CPU 的使用情況。

創(chuàng)建了 15 個 Disruptor 隊列，同時每個隊列都用線程池來往 Disruptor隊列 里面發(fā)送 100W 條數(shù)據(jù)。

消費程序僅僅只是打印一下。

跑了一段時間發(fā)現(xiàn) CPU 使用率確實很高。

同時 dump 線程發(fā)現(xiàn)和生產(chǎn)的現(xiàn)象也是一致的：消費線程都處于 RUNNABLE 狀態(tài)，同時都在執(zhí)行 yield。

通過查詢 Disruptor 官方文檔發(fā)現(xiàn)：

YieldingWaitStrategy 是一種充分壓榨 CPU 的策略，使用自旋 + yield的方式來提高性能。
當(dāng)消費線程（Event Handler threads）的數(shù)量小于 CPU 核心數(shù)時推薦使用該策略。

同時查閱到其他的等待策略 BlockingWaitStrategy （也是默認(rèn)的策略），它使用的是鎖的機(jī)制，對 CPU 的使用率不高。

于是在和之前同樣的條件下將等待策略換為 BlockingWaitStrategy。

和剛才的 CPU 對比會發(fā)現(xiàn)到后面使用率的會有明顯的降低；同時 dump 線程后會發(fā)現(xiàn)大部分線程都處于 waiting 狀態(tài)。

看樣子將等待策略換為 BlockingWaitStrategy 可以減緩 CPU 的使用，

但留意到官方對 YieldingWaitStrategy 的描述里談道：
當(dāng)消費線程（Event Handler threads）的數(shù)量小于 CPU 核心數(shù)時推薦使用該策略。

而現(xiàn)有的使用場景很明顯消費線程數(shù)已經(jīng)大大的超過了核心 CPU 數(shù)了，因為我的使用方式是一個 Disruptor 隊列一個消費者，所以我將隊列調(diào)整為只有 1 個再試試(策略依然是 YieldingWaitStrategy)。

跑了一分鐘，發(fā)現(xiàn) CPU 的使用率一直都比較平穩(wěn)而且不高。

所以排查到此可以有一個結(jié)論了，想要根本解決這個問題需要將我們現(xiàn)有的業(yè)務(wù)拆分；現(xiàn)在是一個應(yīng)用里同時處理了 N 個業(yè)務(wù)，每個業(yè)務(wù)都會使用好幾個 Disruptor 隊列。

由于是在一臺服務(wù)器上運行，所以 CPU 資源都是共享的，這就會導(dǎo)致 CPU 的使用率居高不下。

所以我們的調(diào)整方式如下：

為了快速緩解這個問題，先將等待策略換為 BlockingWaitStrategy，可以有效降低 CPU 的使用率（業(yè)務(wù)上也還能接受）。

第二步就需要將應(yīng)用拆分（上文模擬的一個 Disruptor 隊列），一個應(yīng)用處理一種業(yè)務(wù)類型；然后分別多帶帶部署，這樣也可以互相隔離互不影響。

當(dāng)然還有其他的一些優(yōu)化，因為這也是一個老系統(tǒng)了，這次 dump 線程居然發(fā)現(xiàn)創(chuàng)建了 800+ 的線程。

創(chuàng)建線程池的方式也是核心線程數(shù)、最大線程數(shù)是一樣的，導(dǎo)致一些空閑的線程也得不到回收；這樣會有很多無意義的資源消耗。

所以也會結(jié)合業(yè)務(wù)將創(chuàng)建線程池的方式調(diào)整一下，將線程數(shù)降下來，盡量的物盡其用。

本文的演示代碼已上傳至 GitHub：

https://github.com/crossoverJie/JCSprout

你的點贊與分享是對我最大的支持