前言

在我們開發過程中，無法避免的會出現所謂的垃圾代碼，導致服務器的CPU一直處於100%。但我們應用已經上線，導致服務器CPU居高，但又不知道哪邊出現的問題，我們應該怎麼去找出哪邊的代碼出現問題呢？今天老顧就介紹幾種工具去快速定位。

演示代碼

我們先來編寫一下代碼，新建springboot的maven項目，創建web服務，引入SpringBoot內置web容器，pom.xml關鍵引用jar包如下：

<code>


1.  `<dependency>`

2.  `<groupid>org.springframework.boot/<groupid>`

3.  `<artifactid>spring-boot-starter-web/<artifactid>`

4.  `/<dependency>`


/<code>

創建service：TestWhile

創建Controller：TestWhile

配置文件application.properties

<code>


1.  `server.port=80`

2.  `server.servlet.context-path=/api`


/<code>

打包項目，上傳測試服務器

<code>


1.  `java -jar demo-0.0.1-SNAPSHOT.jar &`


/<code>

打開瀏覽器，訪問死循環方法

打開瀏覽器，地址欄輸入http://xxxx/api/user/testWhile?size=2 返回“Hello 程序執行完畢”，說明調用成功。（開啟了2個死循環）

到此問題代碼，已經在服務器上面跑了。我們發現服務器報警，於是去線上排查。

原生方法

此方法無需額外安裝工具，在沒法連接互聯網的情況下使用此方法排查效果較好。

top、printf都是Linux原生命令，jstack、jstat是jdk自帶命令工具。

很多功能強大的Linux和java診斷工具也是以top、jstack、jstat為基礎命令做的封裝。

注意：jstack、jstat等命令需要jdk完整安裝，linux自帶的openJdk一般無此工具，可以在java的bin目錄下查看是否有這些命令。

找到最耗CPU的進程

命令：top –c，顯示進程運行信息列表

實例：top -c。

交互1：按1，數字1，顯示多核CPU信息。交互2：鍵入P (大寫p)，進程按照CPU使用率排序

我們看出了雙核CPU使用率已經達到100%。

而第一個進程PID是373的就是我們要找的罪魁禍首了；可以看到進程最後一列，COMMAND註釋的進程名：“java -jar demo-0.0.1-SNAPSHOT.jar”。

找到最耗CPU的線程

命令：top -H -p 【PID】，顯示一個進程的線程運行信息列表

實例：top -Hp 373 ，如下圖所示，可以看到多個高耗CPU使用率的線程

轉換線程PID為16進制

命令：printf “%x\\n” 【線程pid】，轉換多個線程數字為十六進制，第4步使用時前面加0x。

查看堆棧，定位線程

命令：jstack 【進程PID】| grep 【線程轉換後十六進制】-A10 ， 使用jstack獲取進程PID堆棧，利用grep定位線程id，打印後續10行信息。

我們通過查看堆棧信息，發現了問題是TestWhile.whileTrue引起的；

而且發現有2個GC線程，看上圖中的“GC task thread#0 (ParallelGC)”，代表垃圾回收線程，該線程會負責進行垃圾回收

存儲堆棧，批量查看

查看堆棧信息，我們也可以換個方法查看，可以先將jstack堆棧信息存儲起來。

命令：jstack 【進程PID】> 【文件】

實例：jstack 373 > demo.dump，存儲373進程的堆棧信息。

再使用cat + grep查找看看後面幾個高CPU線程的堆棧信息。

實例：cat -n demo.dump | grep -A10 '0x196'，如下圖所示：

可以看到線程0x196【線程196】產生堆棧信息，直指方法whileTrue。

GC查看

我們看到上圖中有4個線程中的2個線程沒有看到java代碼，而是GC task thread#0 (ParallelGC)，這個是GC垃圾回收的線程，是不是死循環導致了GC太頻繁，導致CPU使用率居高不下呢？

我們使用jstat看下jvm的GC信息看看。

命令：jstat -gcutil 【進程PID】【毫秒】【打印次數】

實例：jstat -gcutil 373 2000 5，查看373進程的GC信息，每2秒打印一次，共打印5次，如下圖所示：

S0：倖存1區當前使用比例 S1：倖存2區當前使用比例 E：伊甸園區使用比例 O：老年代使用比例 M：元數據區使用比例 CCS：壓縮使用比例 YGC：年輕代垃圾回收次數 FGC：老年代垃圾回收次數 FGCT：老年代垃圾回收消耗時間 GCT：垃圾回收消耗總時間

上面的原生方法查找要遵循一定的步驟，相對有些麻煩點，有沒有比較簡單的方法呢？往下看

Arthas（阿爾薩斯）

Arthas（阿爾薩斯）是阿里巴巴開源出來的一個針對 java 的線上診斷工具，功能非常強大。Arthas 支持JDK 6+，支持Linux/Mac/Windows，採用命令行交互模式，同時提供豐富的 Tab 自動補全功能，進一步方便進行問題的定位和診斷。我們來看看

下載Arthas

1使用arthas-boot（推薦）

下載arthas-boot.jar，然後用java -jar的方式啟動：

<code>


1.  `curl -O https://alibaba.github.io/arthas/arthas-boot.jar` 


2.  `java -jar arthas-boot.jar`


/<code>

按1進入java進程，此時java進程PID已經變成373

進入阿爾薩斯完成，如下圖，可以看到登錄路徑已經變成了[arthas@17376]$，可以輸入dashboard，進入監控頁面了。

監控查看

已經進入Arthas操作界面，輸入dashboard，回車後將看到線程及堆棧信息，如圖所示，arthas已經將cpu高使用率的線程給安排上了。

上面我們就看到有2個線程居高不下，還有GC的數量和耗時。

thread【ID】查看線程

ctrl + c 退出dashboard界面，輸入thread 32查看線程信息，如下圖所示：

可以看到是TestWhile類中的whileTrue方法中的put方法導致cpu使用率升高。

問題一下子就出來了，Arthas功能不單單止於此，可以直接反編譯，看看代碼。

jad反編譯

使用Arthas自帶的反編譯方法jad，輸入命令：

• jad com.rainbow.demo.service.TestWhile*

可以反編譯java的class查看問題函數的具體代碼,如下圖所示：

退出arthas

最後，既然問題已經找到，那就退出Arthas吧。輸入命令：quit

Arthas的功能是非常強大的，這裡就簡單介紹，下一次老顧用專門的文章介紹

老顧在介紹一個更簡單的一個腳本，立刻發現問題所在

show-busy-java-threads

show-busy-java-threads.sh這個工具是useful-scripts工具集的其中一個工具。

show-busy-java-threads用於快速排查Java的CPU性能問題(top us值過高)，自動查出運行的Java進程中消耗CPU多的線程，並打印出其線程棧，從而確定導致性能問題的方法調用。

注意：此工具的核心還是使用jdk的jstack方法，只是在其上做了封裝展示。

下載到當前目錄下

下載地址：https://github.com/oldratlee/useful-scripts/releases

在bin下面有很多工具，我們這次只要show-busy-java-threads.sh

上傳show-busy-java-threads腳本到服務器

一定賦予執行權限

chmod +x show-busy-java-threads

直接運行

<code>
 


1.  `./show-busy-java-threads `


/<code>

如下圖所示，找到了CPU使用率前5高的線程，查找非常迅速。

從前面兩個線程可以看出，與使用原生工具（jstack）看到的一樣。

其他命令

與Arthas一樣，show-busy-java-threads也有一些其他很好用的增強命令：

show-busy-java-threads

從所有的 Java進程中找出最消耗CPU的線程（缺省5個），打印出其線程棧。

show-busy-java-threads -c 3

-c 3：3為n，指定顯示最耗cpu使用率前3的線程。

show-busy-java-threads -c 3 -p 17376

展示進程17376耗費CPU組多的3個線程；

-p 17376 ：17376為進程PID，-p參數指定進程PID。

show-busy-java-threads -s 【指定jstack命令的全路徑】

對於sudo方式的運行，JAVAHOME環境變量不能傳遞給root，而root用戶往往沒有配置JAVAHOME且不方便配置，顯式指定jstack命令的路徑就反而顯得更方便了

show-busy-java-threads -a yao.log

將輸出結果導入到指定文件yao.log中

show-busy-java-threads 3 5

每5秒執行一次，一共執行3次；缺省執行一次，缺省間隔是3秒

總結

今天老顧介紹了3中方法排查服務器CPU負載過高的情況，主要流程是：

1、查看CPU負載過高進程。

2、查看進程中負載高的線程。

3、獲取進程中的堆棧信息。

4、獲取堆棧中對應的線程信息，找到裡面的問題方法。

在排查過程中我們不只使用了原生工具，還使用了增強工具Arthas與show-busy-java-threads，大大簡化了我們排查的步驟。

其實增強工具無非就是在原生方法上面封裝了而已，有很多這種工具都是在原生方法中封裝而成。今天就介紹到這裡，謝謝！！！

最後，歡迎大家在評論區提出自己的見解~

這裡小on君也給大家分享一份自己整理的Java進階寶典《Java核心知識點整理.pdf》，全文覆蓋了JVM、鎖、高併發、反射、mybatis、Spring原理、微服務、Zookeeper、數據庫、數據結構等等一系列的知識點，今天限時免費發放，

閱讀更多 享學課堂online 的文章

關鍵字: 中央處理器 Line 開源