原文：https://www.iteye.com/blog/tyrion-2293369
上午線上某應用的一台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進程：
