一、引子
對于互聯(lián)網(wǎng)公司奕锌，線上CPU飆升的問題很常見（例如某個活動開始衫贬，流量突然飆升時），按照本文的步驟排查歇攻，基本1分鐘即可搞定固惯！特此整理排查方法一篇，供大家參考討論提高缴守。
二葬毫、問題復(fù)現(xiàn)
線上系統(tǒng)突然運(yùn)行緩慢镇辉，CPU飆升，甚至到100%贴捡，以及Full GC次數(shù)過多忽肛，接著就是各種報警：例如接口超時報警等。此時急需快速線上排查問題烂斋。
三屹逛、問題排查
不管什么問題，既然是CPU飆升汛骂，肯定是查一下耗CPU的線程罕模，然后看看GC。
3.1 核心排查步驟
1.執(zhí)行“top”命令：查看所有進(jìn)程占系統(tǒng)CPU的排序帘瞭。極大可能排第一個的就是咱們的java進(jìn)程（COMMAND列）淑掌。PID那一列就是進(jìn)程號。
2.執(zhí)行“top -Hp 進(jìn)程號”命令：查看java進(jìn)程下的所有線程占CPU的情況蝶念。
3.執(zhí)行“printf "%x\n 10"命令 ：后續(xù)查看線程堆棧信息展示的都是十六進(jìn)制抛腕，為了找到咱們的線程堆棧信息，咱們需要把線程號轉(zhuǎn)成16進(jìn)制媒殉。例如,printf "%x\n 10-》打拥５小：a，那么在jstack中線程號就是0xa.
4.執(zhí)行 “jstack 進(jìn)程號 | grep 線程ID” 查找某進(jìn)程下-》線程ID（jstack堆棧信息中的nid）=0xa的線程堆棧信息廷蓉。如果“"VM Thread" os_prio=0 tid=0x00007f871806e000 nid=0xa runnable”全封，第一個雙引號圈起來的就是線程名，如果是“VM Thread”這就是虛擬機(jī)GC回收線程了
5.執(zhí)行“jstat -gcutil 進(jìn)程號 統(tǒng)計間隔毫秒 統(tǒng)計次數(shù)（缺省代表一致統(tǒng)計）”苦酱，查看某進(jìn)程GC持續(xù)變化情況售貌，如果發(fā)現(xiàn)返回中FGC很大且一直增大-》確認(rèn)Full GC! 也可以使用“jmap -heap 進(jìn)程ID”查看一下進(jìn)程的堆內(nèi)從是不是要溢出了给猾，特別是老年代內(nèi)從使用情況一般是達(dá)到閾值(具體看垃圾回收器和啟動時配置的閾值)就會進(jìn)程Full GC疫萤。
6.執(zhí)行“jmap -dump:format=b,file=filename 進(jìn)程ID”，導(dǎo)出某進(jìn)程下內(nèi)存heap輸出到文件中敢伸〕度模可以通過eclipse的mat工具查看內(nèi)存中有哪些對象比較多。
3.2 原因分析
1.內(nèi)存消耗過大池颈，導(dǎo)致Full GC次數(shù)過多
執(zhí)行步驟1-5：
多個線程的CPU都超過了100%尾序，通過jstack命令可以看到這些線程主要是垃圾回收線程-》上一節(jié)步驟2
通過jstat命令監(jiān)控GC情況，可以看到Full GC次數(shù)非常多躯砰，并且次數(shù)在不斷增加每币。--》上一節(jié)步驟5
確定是Full GC,接下來找到具體原因：
生成大量的對象，導(dǎo)致內(nèi)存溢出-》執(zhí)行步驟6琢歇，查看具體內(nèi)存對象占用情況兰怠。
內(nèi)存占用不高梦鉴，但是Full GC次數(shù)還是比較多，此時可能是代碼中手動調(diào)用 System.gc()導(dǎo)致GC次數(shù)過多揭保，這可以通過添加 -XX:+DisableExplicitGC來禁用JVM對顯示GC的響應(yīng)肥橙。
2.代碼中有大量消耗CPU的操作，導(dǎo)致CPU過高秸侣，系統(tǒng)運(yùn)行緩慢存筏；
執(zhí)行步驟1-4：在步驟4jstack，可直接定位到代碼行味榛。例如某些復(fù)雜算法椭坚，甚至算法BUG，無限循環(huán)遞歸等等励负。
3.由于鎖使用不當(dāng)藕溅，導(dǎo)致死鎖。
執(zhí)行步驟1-4： 如果有死鎖继榆，會直接提示巾表。關(guān)鍵字：deadlock.步驟四，會打印出業(yè)務(wù)死鎖的位置略吨。
造成死鎖的原因：最典型的就是2個線程互相等待對方持有的鎖集币。
4.隨機(jī)出現(xiàn)大量線程訪問接口緩慢。
代碼某個位置有阻塞性的操作翠忠，導(dǎo)致該功能調(diào)用整體比較耗時鞠苟，但出現(xiàn)是比較隨機(jī)的；平時消耗的CPU不多秽之，而且占用的內(nèi)存也不高当娱。
思路：
首先找到該接口，通過壓測工具不斷加大訪問力度考榨，大量線程將阻塞于該阻塞點跨细。
執(zhí)行步驟1-4：
"http-nio-8080-exec-4" #31 daemon prio=5 os_prio=31 tid=0x00007fd08d0fa000 nid=0x6403 waiting on condition [0x00007000033db000]
java.lang.Thread.State: TIMED_WAITING (sleeping)-》期限等待
at java.lang.Thread.sleep(Native Method)
at java.lang.Thread.sleep(Thread.java:340)
at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:386)
at com.*.user.controller.UserController.detail(UserController.java:18)-》業(yè)務(wù)代碼阻塞點
如上圖，找到業(yè)務(wù)代碼阻塞點河质，這里業(yè)務(wù)代碼使用了TimeUnit.sleep()方法冀惭，使線程進(jìn)入了TIMED_WAITING(期限等待)狀態(tài)。
5.某個線程由于某種原因而進(jìn)入WAITING狀態(tài)掀鹅，此時該功能整體不可用散休，但是無法復(fù)現(xiàn)；
執(zhí)行步驟1-4：jstack多查詢幾次乐尊，每次間隔30秒戚丸，對比一直停留在parking 導(dǎo)致的WAITING狀態(tài)的線程。例如CountDownLatch倒計時器扔嵌，使得相關(guān)線程等待->AQS->LockSupport.park()限府。
"Thread-0" #11 prio=5 os_prio=31 tid=0x00007f9de08c7000 nid=0x5603 waiting on condition [0x0000700001f89000]
java.lang.Thread.State: WAITING (parking) ->無期限等待
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at com..SyncTask.lambda0(SyncTask.java:8)-》業(yè)務(wù)代碼阻塞點
at com..SyncTask$$Lambda$1/1791741888.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748)
原文鏈接：https://blog.csdn.net/m0_55849656/article/details/125234508
另：jstack命令詳解 https://zhuanlan.zhihu.com/p/475571849
