前言
到了年底果然都不太平，最近又收到了運維報警：表示有些伺服器負載非常高，讓我們定位問題。
還真是想什麼來什麼，前些天還故意把某些伺服器的負載提高（沒錯，老闆讓我寫個 BUG！），不過還好是不同的環境互相沒有影響。
定位問題
拿到問題後首先去伺服器上看了看，發現執行的只有我們的 Java 應用。於是先用 ps 命令拿到了應用的 PID。
接著使用 top -Hp pid 將這個程式的執行緒顯示出來。輸入大寫的 P 可以將執行緒按照 CPU 使用比例排序，於是得到以下結果。
果然某些執行緒的 CPU 使用率非常高。
為了方便定位問題我立馬使用 jstack pid > pid.log 將執行緒棧 dump 到日誌檔案中。
我在上面 100% 的執行緒中隨機選了一個 pid=194283 轉換為 16 進位制（2f6eb）後線上程快照中查詢：
因為執行緒快照中執行緒 ID 都是16進位制存放。
發現這是 Disruptor 的一個堆疊，前段時間正好解決過一個由於 Disruptor 佇列引起的一次 OOM：強如 Disruptor 也發生記憶體溢位？
沒想到又來一出。
為了更加直觀的檢視執行緒的狀態資訊，我將快照資訊上傳到專門分析的平臺上。
其中有一項選單展示了所有消耗 CPU 的執行緒，我仔細看了下發現幾乎都是和上面的堆疊一樣。
也就是說都是 Disruptor 佇列的堆疊，同時都在執行 java.lang.Thread.yield 函式。
眾所周知 yield 函式會讓當前執行緒讓出 CPU 資源，再讓其他執行緒來競爭。
根據剛才的執行緒快照發現處於 RUNNABLE 狀態並且都在執行 yield 函式的執行緒大概有 30幾個。
因此初步判斷為大量執行緒執行 yield 函式之後互相競爭導致 CPU 使用率增高，而通過對堆疊發現是和使用 Disruptor 有關。
解決問題
而後我檢視了程式碼，發現是根據每一個業務場景在內部都會使用 2 個 Disruptor 佇列來解耦。
假設現在有 7 個業務型別，那就等於是建立 2*7=14 個 Disruptor 佇列，同時每個佇列有一個消費者，也就是總共有 14 個消費者（生產環境更多）。
同時發現配置的消費等待策略為 YieldingWaitStrategy 這種等待策略確實會執行 yield 來讓出 CPU。
程式碼如下：
初步看來和這個等待策略有很大的關係。
本地模擬
為了驗證，我在本地建立了 15 個 Disruptor 佇列同時結合監控觀察 CPU 的使用情況。
建立了 15 個 Disruptor 佇列，同時每個佇列都用執行緒池來往 Disruptor佇列 裡面傳送 100W 條資料。
消費程式僅僅只是列印一下。
跑了一段時間發現 CPU 使用率確實很高。
同時 dump 執行緒發現和生產的現象也是一致的：消費執行緒都處於 RUNNABLE 狀態，同時都在執行 yield。
通過查詢 Disruptor 官方文件發現：
YieldingWaitStrategy 是一種充分壓榨 CPU 的策略，使用
自旋 + yield的方式來提高效能。 當消費執行緒（Event Handler threads）的數量小於 CPU 核心數時推薦使用該策略。
同時查閱到其他的等待策略 BlockingWaitStrategy （也是預設的策略），它使用的是鎖的機制，對 CPU 的使用率不高。
於是在和之前同樣的條件下將等待策略換為 BlockingWaitStrategy。
和剛才的 CPU 對比會發現到後面使用率的會有明顯的降低；同時 dump 執行緒後會發現大部分執行緒都處於 waiting 狀態。
優化解決
看樣子將等待策略換為 BlockingWaitStrategy 可以減緩 CPU 的使用，
但留意到官方對 YieldingWaitStrategy 的描述裡談道：
當消費執行緒（Event Handler threads）的數量小於 CPU 核心數時推薦使用該策略。
而現有的使用場景很明顯消費執行緒數已經大大的超過了核心 CPU 數了，因為我的使用方式是一個 Disruptor 佇列一個消費者，所以我將佇列調整為只有 1 個再試試(策略依然是 YieldingWaitStrategy)。
跑了一分鐘，發現 CPU 的使用率一直都比較平穩而且不高。
總結
所以排查到此可以有一個結論了，想要根本解決這個問題需要將我們現有的業務拆分；現在是一個應用裡同時處理了 N 個業務，每個業務都會使用好幾個 Disruptor 佇列。
由於是在一臺伺服器上執行，所以 CPU 資源都是共享的，這就會導致 CPU 的使用率居高不下。
所以我們的調整方式如下：
- 為了快速緩解這個問題，先將等待策略換為
BlockingWaitStrategy，可以有效降低 CPU 的使用率（業務上也還能接受）。 - 第二步就需要將應用拆分（上文模擬的一個
Disruptor佇列），一個應用處理一種業務型別；然後分別單獨部署，這樣也可以互相隔離互不影響。
當然還有其他的一些優化，因為這也是一個老系統了，這次 dump 執行緒居然發現建立了 800+ 的執行緒。
建立執行緒池的方式也是核心執行緒數、最大執行緒數是一樣的，導致一些空閒的執行緒也得不到回收；這樣會有很多無意義的資源消耗。
所以也會結合業務將建立執行緒池的方式調整一下，將執行緒數降下來，儘量的物盡其用。
本文的演示程式碼已上傳至 GitHub：
你的點贊與分享是對我最大的支援
