https://wangcw.blog.csdn.net/article/details/86242263?utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control
以下驗證
當系統出現卡頓或者應用程序的響應速度非常慢，就可能要考慮到服務器上排查一番，以下是我常用的排查流程：
1、top：觀察占用CPU或者MEN（內存）使用情況最高的進程,記錄PID；
TIP:
（1）、“1” 顯示出多個邏輯CPU使用情況；
（2）、“X” 高亮顯示CPU列，並排序,"Z"紅色展示；
（3）、“shift + <” 或者 “shift + >” 變更高亮的列；
（4）、“F”配合 “空格”指定需要展示的列；
（5）、“S”設置刷新的間隔時間；
2、top -Hp PID：觀察該PID對應進程的占用情況。“shift + h” 開啟線程顯示，觀察CPU占用較高的線程有哪些，記錄對應TID；
3、printf "%x\n" TID ：將線程對應PID轉為 16進制數（TID16）；
4、jstack -F PID | grep -A 30 "nid=0x + TID16" > /java/PID.txt：查看該線程的堆棧信息；
jstack -F PID > /java/PID.txt：查看該線程的堆棧信息；
5、通過線程的堆棧信息，定位到CPU占用過高的代碼，分析其原因。
TIP:
（1）、通常可以結合jstat來分析JVM中的內存信息；（如jstat -gcutil PID 1000 10 、jstat -gc PID 1000 10、jstat -gccause PID 1000 10）
（2）、jmap -heap PID來查看整個JVM內存狀態 ；（要注意的是在使用CMS GC情況下，jmap -heap的執行有可能會導致JAVA進程掛起）
（3）、jmap -histo PID 查看JVM堆中對象詳細占用情況;
（4）、jmap -dump:format=b,file=文件名 [pid]導出整個JVM中內存信息。
常見服務器CPU過高的問題原因和對應解決方案：
1、方法中存在讀寫文件流的操作，高並發時每個請求產生一個文件流，導致系統CPU急增。
解決方案：
從線程棧日志信息中，找出導致CPU高的線程方法。讀寫文件流操作移出方法中，避免每次請求都產生一個文件流。
2、方法中使用了多線程，未使用連接池或使用了Executors.newCachedThreadPool()創建的接連池，高並發時創建出過多的后台線程。
解決方案：
a、使用jstack命令統計出線程數量；
b、找出程序中創建線程代碼；
c、使用Executors.newFixedThreadPool(thread_size)創建固定數量的線程池（線程數固定，無法無收），或者使用new ThreadPoolExecutor(coreSize, maxSize, 60L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>())直接構造線程池。
3、發現是gc線程導致的CPU問題比較費時
解決方案：
a、查看一下gc策略是否合理；
b、用命令jmap -histo [PID] 分析是哪個類占用內存比較多，分析出可能存在內存泄露的地方；
c、jvm內存調優，可使用Jconsole、visalvm、probe等工具查看java虛擬機中方法區、堆區（新生代、幸存代、老年代）、線程棧的內存分配，根據實際情況進行優化。
4、代碼中存在死循環、死鎖
解決方案：
直接通過jstack獲取到出問題的線程的堆棧信息，分析代碼邏輯。
————————————————
版權聲明：本文為CSDN博主「JdbcUtils」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_33404395/article/details/86242263