又是一個百無聊賴的早晨，我在快樂地摸魚，工作群響了：離線系統登錄不上了。我第一反應是不科學啊，系統已經很久改動過了...趕緊上生產環境看看，CPU高達1200%。接著又是熟練地敲出那幾行排查CPU過高的命令

top-H-ppid查看java占用率最高的幾條線程
jstackpid>xxx.txt打印線程快照
jmap-heappid查看堆內存情況

看這玩意啥都看不出來，感覺是系統對象沒有釋放，在瘋狂GC，但是因為FULL GC的時候已經STW了，所以無法查看到底是哪個線程出了問題。然后過了10分鐘系統突然又好了....堵塞的操作已經完成，gc能正?；厥樟恕?/p>

然后過了兩分鐘又卡死了，我先重啟了系統，后面再分析分析。

等系統沒什么人用的時候，我再試著重現一下問題，打開系統一頓亂點，結果是點開某個功能的詳情時系統卡住了，CPU又飚上去了，喜聞樂見~問題定位到了，再實錘一下之前是不是這個問題，我看了一下localhost_access_log日志發現，確實是這個接口卡了一千多秒。

nginx日志

因為離線沒什么人使用，所以問題過了很久再暴露出來?？戳艘幌麓a，主要是同事業務邏輯問題，有個參數沒傳進去，導致 sql 走了全表掃描，數據很多，要查很久，查到了幾百萬的數據，gc 也無法回收。

還好內存夠大，要不然早就 OOM 了。

復盤

一開始我以為是某個接口調了很多次并發太高導致的，沒想到點一下詳情系統就掛了。。我們可以看到CPU在GC回收的時候STW，是沒有線程能占用到CPU的，所以top -H -p pid 只能看到CPU全被GC線程占用了。如果是某個接口并發太高導致的，我們可以看jstack線程快照，里面是會有這個接口在執行的記錄。

還有一個問題就是說系統GC卡了10-20分鐘，卻沒有報OOM，還是一直在堵塞狀態，后面還正常了一小會，這個是需要看堆內存的情況...

因為比較難排查所以只是通過現象知道GC還是可以回收一點點垃圾的

總結

1、CPU100%的時候可以打印線程快照jstack pid，查看是哪個線程占用了CPU，一般都是某個業務線程阻塞無法進行GC回收導致。

2、可以查看localhost_access_log查看系統接口用時，一般用時很久的都是有問題的接口。

3、同事的業務代碼參數沒有傳，導致全表掃描直接卡死系統。

審核編輯：湯梓紅