JVM的CPU資源占用過高問題的排查過程是怎么樣的

今天就跟大家聊聊有關(guān)JVM的CPU資源占用過高問題的排查過程是怎么樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

上午線上某應(yīng)用的一臺JVM的CPU占比突然飆高到192%，并且一直下不來，導(dǎo)致監(jiān)控一直告警，好久沒處理這種問題了，現(xiàn)在將問題排查步驟總結(jié)記錄一下。（以下的圖都不是線上問題的截圖，涉及到公司業(yè)務(wù)）

1.通過top命令查看當(dāng)前機(jī)器的CPU使用情況

此時發(fā)現(xiàn)如果是Java的進(jìn)程占用過高，并且一直下不來，則排查是什么線程導(dǎo)致占比過高。以圖中進(jìn)程舉例，假如發(fā)現(xiàn)PID為31357的Java進(jìn)程占CPU比一直很高，則記錄下它的PID

2.查看Java進(jìn)程里面的線程的占用情況

top -H -p 31357

說明：-H 指顯示線程，-p 是指定進(jìn)程

可以看到CPU占用較高的線程，記下他們的PID，假設(shè)這里31357的CPU占比一直是50%

3.通過jstack命令獲取占用資源異常的線程棧，可暫時保存到一個文件中查看

jstack 31357 > jstack.31357.log

以上能看到指定線程的堆棧信息。

如果想看到關(guān)于線程中的鎖的附加信息，可以加一個-l參數(shù)

4.上面方法用于進(jìn)程正常情況下的堆棧打印,今天碰到的是用jstack -l命令沒有響應(yīng)，估計是CPU一直站著不能執(zhí)行正常的命令，根據(jù)提示［The -F option can be used when the target process is not responding］只能放大招了。

jstack -F “PID” > jstack.“PID”.txt

吐出的實際日志結(jié)果如下：

發(fā)現(xiàn)一大坨線程阻塞了，有用的結(jié)果在這里：

顯然一直在跑的是19576這個線程，一直在執(zhí)行EXCEL導(dǎo)出的相關(guān)方法，問題就出在這里，下面的任務(wù)就是排查這個地方的代碼邏輯了。

jstack命令格式:

jstack [ option ] pid

參數(shù)說明:

-F jstack [-l] pid無法響應(yīng)時，強制打印堆棧

-l l長列表. 打印關(guān)于鎖的附加信息,例如屬于java.util.concurrent的ownable synchronizers列表.

-m 混合模式輸出(包括java和本地c/c++片段)堆棧。

pid: java應(yīng)用程序的進(jìn)程號

記得沒錯的話這幾個參數(shù)是互斥的，不能聯(lián)合使用。

5.后來搜資料發(fā)現(xiàn)用jps命令查看java進(jìn)程的pid更實用：

命令格式

jps [ options ] [ hostid ]

參數(shù)說明

-m 輸出傳遞給main方法的參數(shù)，如果是內(nèi)嵌的JVM則輸出為null。

-l 輸出應(yīng)用程序主類的完整包名，或者是應(yīng)用程序JAR文件的完整路徑。

-v 輸出傳給JVM的參數(shù)。

三個參數(shù)加在一起顯示更詳細(xì)的信息：

發(fā)現(xiàn)這些Java進(jìn)程的啟動參數(shù)中開放了JMX的遠(yuǎn)程端口，正常情況下可以通過jconsole遠(yuǎn)程連接過去看到JVM的日常參數(shù)。比如本地訪問上圖中的pay.war進(jìn)程：

看完上述內(nèi)容，你們對JVM的CPU資源占用過高問題的排查過程是怎么樣的有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。