好久沒寫技術(shù)文章了，今天下班“早”，簡單叨叨一篇。

早下班的原因說起來也有點(diǎn)搞笑，是因?yàn)榻∩頃r(shí)候杠鈴把手上砸了個(gè)口子。砸傷當(dāng)時(shí)我看了一眼，雖然很痛但骨頭沒事，竟然心中還有一絲慶幸?？p針吧，有點(diǎn)夸張，不處理吧，還挺深。于是，我在從醫(yī)院處理完傷口后，有了這篇文章。

好了，言歸正傳。

CPU 升高問題案例

市面上通常對(duì)于 CPU 問題排查的案例面試比較少，基本上都在講：如果 CPU 升到 100% 怎么辦？

這確實(shí)是個(gè)高頻問題，必須需要流利回答。之前也寫過一篇文章，可以參考：

圖片

重點(diǎn)問題！CPU利用率過高排查思路｜原創(chuàng)

真實(shí)案例

這是一個(gè)今天發(fā)生的真實(shí)案例（相關(guān)信息已脫敏處理，不影響案例本質(zhì)）。

問題如下：這是一個(gè)比較大項(xiàng)目改動(dòng)，改造的過程中涉及到了相當(dāng)多下游接口的改動(dòng)和相當(dāng)多的依賴包。今天在上線發(fā)布后經(jīng)過接口和功能驗(yàn)證，需求發(fā)布成功。

但是接著，我發(fā)布完成后才發(fā)現(xiàn)機(jī)器的平均 CPU 負(fù)載升高，平均 CPU 負(fù)載幾乎升高了有 5-8 %，最高負(fù)載更是超過了 CPU 安全水位線。如此多的改動(dòng)，到底是什么導(dǎo)致了 CPU 負(fù)載的上升？

我自己用 python 花了張圖，大概下面這個(gè)樣子

圖片

問題出現(xiàn)，CPU 升高

快速處理： 我先快速對(duì)比了一下 CPU 負(fù)載升高的時(shí)間點(diǎn)，和發(fā)布時(shí)間基本對(duì)應(yīng)，基本可以判斷是本次發(fā)布引起的。雖然并沒有影響到業(yè)務(wù)，但是發(fā)現(xiàn)問題后，我還是第一時(shí)間做了回滾處理。

注意：發(fā)布過程中出現(xiàn)任何問題不要想排查問題原因，直接回滾，血淚教訓(xùn)的鐵律

排查問題

我排查問題的思路如下：

1. 由于想到本次變更有很多新接口的引入，也有一些接口的對(duì)比代碼，會(huì)帶來額外的性能消耗，所以我先對(duì)比了發(fā)布前后的接口遠(yuǎn)程調(diào)用情況，結(jié)果是調(diào)用量沒有明顯變化，RT 也正常。
2. 服務(wù)也有 kafka 消息處理，同樣檢查消息組件情況，調(diào)用量沒有變化。
3. 會(huì)不會(huì)是 GC 太多導(dǎo)致？檢查 JVM 情況，依舊正常，甚至還因?yàn)橹貑C(jī)器表現(xiàn)要比之前好……
4. 因?yàn)橛玫搅司€程池，會(huì)不會(huì)是因?yàn)槭褂镁€程池不合理，或者有什么死循環(huán)之類的。檢查活躍線程情況，依舊和發(fā)布前相似。
5. 那只能考慮是因?yàn)橐氲哪硞€(gè)依賴引起的了，他導(dǎo)致了預(yù)期外的變化。

問題引入的依賴有很多，到底是哪個(gè)依賴引入的？我難道一個(gè)個(gè)下掉去排查嗎？

排除法，這也確實(shí)是一種辦法，只不過是太辛苦了，事倍功半。更不用說還需要下掉相關(guān)代碼，還得不斷去耗時(shí)發(fā)布，實(shí)在是繁瑣。

怎么辦呢？不賣關(guān)子了，直接上 Arthas。

Async-profiler

Arthas 使用 async-profiler 生成 CPU/內(nèi)存火焰圖進(jìn)行性能分析，彌補(bǔ)了之前內(nèi)存分析的不足。

async-profiler 是一款開源的 Java 性能分析工具，原理是基于 HotSpot 的 API，以微乎其微的性能開銷收集程序運(yùn)行中的堆棧信息、內(nèi)存分配等信息進(jìn)行分析。

官網(wǎng)：https://github.com/async-profiler/async-profiler

我們常用的是 CPU 性能分析和 Heap 內(nèi)存分配分析。在進(jìn)行 CPU 性能分析時(shí)，僅需要非常低的性能開銷就可以進(jìn)行分析。

在進(jìn)行 Heap 分配分析時(shí)，async-profiler 工具會(huì)收集內(nèi)存分配信息，而不是去檢測占用 CPU 的代碼。async-profiler 不使用侵入性的技術(shù)，例如字節(jié)碼檢測工具或者探針檢測等，這也說明 async-profiler 的內(nèi)存分配分析像 CPU 性能分析一樣，不會(huì)產(chǎn)生太大的性能開銷，同時(shí)也不用寫出龐大的堆棧文件再去進(jìn)行進(jìn)一步處理，。

async-profiler 工具在采樣后可以生成采樣結(jié)果的日志報(bào)告，也可以生成 SVG 格式的火焰圖。

圖片

具體使用大家直接去官網(wǎng)看文檔吧，有不懂留言。我這里直接說使用

使用 async-profiler 排查問題

進(jìn)入測試服務(wù)器控制臺(tái)，使用 JPS 命令查看 PID 信息。

?  develop jps
2800 Jps
528 TestCode
2450 Launcher

假設(shè)運(yùn)行程序的名是 TestCode，可以看到對(duì)應(yīng)的 PID 是 528。

使用下面命令：

./profiler.sh -d 20 -f 528.svg 528

對(duì) 528 號(hào)進(jìn)程采樣20秒，然后得到生成的 528.svg 文件，然后我們使用瀏覽器打開這個(gè)文件，可以看到 CPU 的使用火焰圖，如下（這里用網(wǎng)絡(luò)圖片代替）：

圖片

關(guān)于火焰圖怎么看，一言以蔽之：火焰圖里，橫條越長，代表使用的越多，從下到上是調(diào)用堆棧信息。 在這個(gè)圖里可以看到 main 方法上面的調(diào)用中 hotmethod3 方法的 CPU 使用是最多的，點(diǎn)擊這個(gè)方法。還可能看到更詳細(xì)的信息。

那么我們現(xiàn)在只需要查找 hotmethod3 使用的地方在哪里，就可以定位到問題代碼。

當(dāng)然，上面的是個(gè)代替 case，告訴你怎么看這個(gè)火焰圖。真實(shí)的 case 要比這個(gè)更難排查。如下圖，問題代碼是個(gè)線程，是由某個(gè)類調(diào)用的：

圖片

排查問題依賴引入

問題代碼是一個(gè) Thread 的 run 方法引起的，那么是誰調(diào)用的他呢？這個(gè)類的信息我打碼了，假設(shè)為 ClassA。

但是排查代碼，ClassA 根本沒有被項(xiàng)目代碼直接的調(diào)用，于是我找到了這個(gè) CalssA 所屬的依賴包 dep-demoA，看他是誰引入的。

./gradlew :項(xiàng)目名:dependencyInsight --dependency dep-demoA

這個(gè)命令會(huì)打出一個(gè)項(xiàng)目的依賴樹，結(jié)果如下：

+--- com.ali:dep-demoA:1.0.0 (*)
\--- com.ali:dep-demoB:1.0.0
     \--- com.ali:dep-demoC:1.0.0

如上結(jié)果，項(xiàng)目中我是用的是 dep-demoC，結(jié)果他同時(shí)引入了 dep-demoB，我看了下這個(gè) demoB，他很可能會(huì)跟 arthas 類似，通過 Java Agent技術(shù)和字節(jié)碼增強(qiáng)技術(shù)以實(shí)現(xiàn)一定的功能，這對(duì)程序是非常有損耗的。（所以線上不能開 arthas）

嘗試排除 demoB，代碼如下：

all*.exclude group: "com.ali", module: "dep-demoB"

然后重啟項(xiàng)目，CPU 負(fù)載下降，回歸到正常水平，問題解決。

圖片