性能分析小案例系列，可以通過下面鏈接查看哦
https://www.cnblogs.com/poloyy/category/1814570.html
ps：這些分析小案例不能保證完全准確哦，是博主學習過程中的總結，僅做參考
前提
本機有一個很占用 CPU 的項目，放在了 Tomcat 下啟動着
如何定位
Jmeter 聚合報告
- 可以看到平均響應時間不斷的上升，但是吞吐量（TPS）很低
- 平均響應時間一般超過 1s，就要排除網絡有沒有瓶頸
排查網絡是否有瓶頸
在 cmd ping 自己的服務器 ip 地址，看是否有很大的延時或丟包
可以看到，沒有丟包，而且延時也很低，證明網絡沒有問題
在服務器中，通過 top 查看是否有進程的用戶態（us）過高
top
- 可以看到是 Java 進程導致 CPU 使用率賊高，已經占滿了四個 CPU
- 記住該進程 PID
通過 ps 命令確認具體是哪個進程
ps -aux | grep 2838
很明顯，就是我們 Java 程序所在的 Tomcat 進程啦
通過 top 查看 Java 進程的線程執行情況
2838 是進程 id 哦（pid）
top -Hp 2838
- 上面的 PID 就是線程的 PID
- 按照線程的 CPU 使用率從高到低排序
將排在前面的線程 PID 轉換成十六進制
printf "%x\n" 4808
打印 Java 線程棧的信息
jstack 2838 | grep 12c8 -A30
- 2838：java 進程
- 12c8：線程十六進制
- -A30：打印 30 行
- 包含：包名、類名、代碼行信息，可以快速定位到某行代碼導致該線程 CPU 使用率過高
- jstack：JDK 自帶命令
分析思路過程
- 使用 Jmeter 進行壓測，通過觀察聚合報告，發現 TPS 很低只有2.幾，但是響應時間很高
- 響應時間很高首先要排查是否是網路原因，通過 ping 服務器的 IP 發現延時很低，不存在網絡問題
- 通過 top 查看服務端的系統資源情況，發現用戶態 CPU 使用率比較高，即存在占用 CPU 高的進程，查看進程列表，發現一個 Java 進程的 CPU 占用率特別高
- 通過 ps 命令確認該進程的詳細信息
- 通過 top -Hp 查看該進程的所有線程信息
- 將排在前面的 Java 線程號打印成 16 進制字符串
- 通過 jstack 打印 Java 線程棧的信息，可以發現是某一行代碼的問題