上篇講到windows下排查cpu過高原因，后續將demo放到了linux系統里面，再寫篇linux下排查cpu高
1、首先查看當前linux下跑的cpu
命令：top，查看cpu使用異常的進程PID，我本地環境的異常進程時71983
2、查看所有java進程找到具體哪個項目的進程
命令：ps - ef | grep java 查看具體是哪個項目 可以看到71983是我的一個websocket-recive的demo項目
3、使用top -H -p PID 查看異常線程
命令： top -H -p 進程號(71983)，查看此項目的異常線程，可以看到72331這個線程一直再占用cpu
4、步驟三展示PID是10進制的，系統語言記錄的是16進制需要轉換
命令：printf "%x\n" 線程號(72331)
5、使用jdk的命令 jstack 進程號(71983) | grep 16進制線程號(11a8b) -A90
命令：jstack 進程號(71983) | grep 16進制線程號(11a8b) -A90 可以找到指定異常線程的代碼所在
6、可以看到對應的實體類中對應的代碼邏輯
分析后得出結論：
線程會一直查詢活躍線程和線程隊列是否大於0。此時所有線程都不會釋放，導致cpu飆升。應該在隊列沒數據時和不存在可用線程后休眠
7、重新上傳項目后，查看CPU使用，會發現問題項目所用cpu降下來了。
注意事項：
如果提示 -bash: jstack: command not found，則可以找到jdk的目錄，進入bin目錄，再執行 ./jstack 進程號 | grep 16進制異常線程號 -A90 即可。
如果提示 well-known file is not secure，則是因為賬號權限的問題。在/tmp/hsperfdata_$USER/目錄，有一個以進程號命名的文件，當我們執行jmap或者jstack出現上敘信息時，先檢查執行該命令的用戶是否和hsperfdata_$USER這個文件所屬的用戶一致，如果不一致，切換至成一致再執行。執行：sudo -u 有權限的賬號 ./jstack 進程號 | grep 16進制異常線程號 -A50 即可。