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

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

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

1.通過top命令查看當前機器的CPU使用情況

此時發現如果是Java的進程占用過高，并且一直下不來，則排查是什么線程導致占比過高。以圖中進程舉例，假如發現PID為31357的Java進程占CPU比一直很高，則記錄下它的PID

2.查看Java進程里面的線程的占用情況

top -H -p 31357

說明：-H 指顯示線程，-p 是指定進程

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

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

jstack 31357 > jstack.31357.log

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

如果想看到關于線程中的鎖的附加信息，可以加一個-l參數

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

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

吐出的實際日志結果如下：

發現一大坨線程阻塞了，有用的結果在這里：

顯然一直在跑的是19576這個線程，一直在執行EXCEL導出的相關方法，問題就出在這里，下面的任務就是排查這個地方的代碼邏輯了。

jstack命令格式:

jstack [ option ] pid

參數說明:

-F jstack [-l] pid無法響應時，強制打印堆棧

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

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

pid: java應用程序的進程號

記得沒錯的話這幾個參數是互斥的，不能聯合使用。

5.后來搜資料發現用jps命令查看java進程的pid更實用：

命令格式

jps [ options ] [ hostid ]

參數說明

-m 輸出傳遞給main方法的參數，如果是內嵌的JVM則輸出為null。

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

-v 輸出傳給JVM的參數。

三個參數加在一起顯示更詳細的信息：

發現這些Java進程的啟動參數中開放了JMX的遠程端口，正常情況下可以通過jconsole遠程連接過去看到JVM的日常參數。比如本地訪問上圖中的pay.war進程：

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