點(diǎn)一下詳情系統(tǒng)掛了，CPU100%
又是一個(gè)百無聊賴的早晨，我在快樂地摸魚，工作群響了：離線系統(tǒng)登錄不上了。我第一反應(yīng)是不科學(xué)啊，系統(tǒng)已經(jīng)很久改動(dòng)過了...趕緊上生產(chǎn)環(huán)境看看，CPU高達(dá)1200%。接著又是熟練地敲出那幾行排查CPU過高的命令
top -H -p pid查看java占用率最高的幾條線程
jstack pid > xxx.txt 打印線程快照
jmap -heap pid 查看堆內(nèi)存情況
看這玩意啥都看不出來，感覺是系統(tǒng)對(duì)象沒有釋放，在瘋狂GC，但是因?yàn)镕ULL GC的時(shí)候已經(jīng)STW了，所以無法查看到底是哪個(gè)線程出了問題。然后過了10分鐘系統(tǒng)突然又好了....堵塞的操作已經(jīng)完成，gc能正?；厥樟恕?/p>
然后過了兩分鐘又卡死了，我先重啟了系統(tǒng)，后面再分析分析。
等系統(tǒng)沒什么人用的時(shí)候，我再試著重現(xiàn)一下問題，打開系統(tǒng)一頓亂點(diǎn)，結(jié)果是點(diǎn)開某個(gè)功能的詳情時(shí)系統(tǒng)卡住了，CPU又飚上去了，喜聞樂見~問題定位到了，再實(shí)錘一下之前是不是這個(gè)問題，我看了一下localhost_access_log日志發(fā)現(xiàn)，確實(shí)是這個(gè)接口卡了一千多秒。
因?yàn)殡x線沒什么人使用，所以問題過了很久再暴露出來?？戳艘幌麓a，主要是同事業(yè)務(wù)邏輯問題，有個(gè)參數(shù)沒傳進(jìn)去，導(dǎo)致 sql 走了全表掃描，數(shù)據(jù)很多，要查很久，查到了幾百萬的數(shù)據(jù)，gc 也無法回收。
還好內(nèi)存夠大，要不然早就 OOM 了。
復(fù)盤
一開始我以為是某個(gè)接口調(diào)了很多次并發(fā)太高導(dǎo)致的，沒想到點(diǎn)一下詳情系統(tǒng)就掛了。。我們可以看到CPU在GC回收的時(shí)候STW，是沒有線程能占用到CPU的，所以top -H -p pid 只能看到CPU全被GC線程占用了。如果是某個(gè)接口并發(fā)太高導(dǎo)致的，我們可以看jstack線程快照，里面是會(huì)有這個(gè)接口在執(zhí)行的記錄。
還有一個(gè)問題就是說系統(tǒng)GC卡了10-20分鐘，卻沒有報(bào)OOM，還是一直在堵塞狀態(tài)，后面還正常了一小會(huì)，這個(gè)是需要看堆內(nèi)存的情況...
因?yàn)楸容^難排查所以只是通過現(xiàn)象知道GC還是可以回收一點(diǎn)點(diǎn)垃圾的
總結(jié)
1、CPU100%的時(shí)候可以打印線程快照jstack pid，查看是哪個(gè)線程占用了CPU，一般都是某個(gè)業(yè)務(wù)線程阻塞無法進(jìn)行GC回收導(dǎo)致。
2、可以查看localhost_access_log查看系統(tǒng)接口用時(shí)，一般用時(shí)很久的都是有問題的接口。
3、同事的業(yè)務(wù)代碼參數(shù)沒有傳，導(dǎo)致全表掃描直接卡死系統(tǒng)。
來源：juejin.cn/post/7233307834456129593
推薦 1. 優(yōu)秀的 Java 代碼都是如何分層的 ？看了直呼NB！
最近面試BAT，整理一份面試資料《Java面試BATJ通關(guān)手冊(cè)》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。 獲取方式：點(diǎn)“在看”，關(guān)注公眾號(hào)并回復(fù) Java 領(lǐng)取，更多內(nèi)容陸續(xù)奉上。 PS：因公眾號(hào)平臺(tái)更改了推送規(guī)則，如果不想錯(cuò)過內(nèi)容，記得讀完點(diǎn)一下“在看”，加個(gè)“星標(biāo)”，這樣每次新文章推送才會(huì)第一時(shí)間出現(xiàn)在你的訂閱列里。 點(diǎn)“在看”支持呀，謝謝啦
