擴充閱讀
JVM FULL GC 生產問題 I-多執行緒通用實現
JVM FULL GC 生產問題 II-如何定位記憶體洩露？ 執行緒通用實現
JVM FULL GC 生產問題 III-多執行緒執行佇列的封裝實現，進一步抽象
jvisualvm java 效能分析工具
jvm-44-jvm 記憶體效能分析工具 Eclipse Memory Analyzer Tool (MAT) / 記憶體分析器 (MAT)
jvm-45-jvm dump 檔案記憶體介紹+獲取方式+堆記憶體可視分析化工具
jvm-46-jvm Thread Dump 執行緒的堆疊跟蹤資訊+獲取方式+可視分析化工具 FastThread
jvm-47-jvm GC 日誌獲取方式+可視分析化工具 GcViewer
jvm-48-java 變更導致壓測應用效能下降，如何分析定位原因？
jvm-49-linux 伺服器使用率升高應該如何排查分析？
前言
大家好，我是老馬。
java 的效能下降，相信每一位小夥伴都遇到過。
測試在壓測環境，發現因為了升級了一下日誌包元件，導致效能下降厲害（30%）。
如何分析原因？
思路
程式碼是否真的存在問題
是否所有的效能都下降?
如果全部下降，則針對升級的部分做程式碼分析+本地結合 jvisual 分析慢在哪裡即可。
發現不是，那麼就針對這一個應用具體分析。
這裡發現就是特定應用的一個壓測變慢了。
QPS 下降初步判斷
整體看是壓測的 QPS 下降。
隨便抽取幾筆日誌檢視，大部分的耗時在 10ms 左右，但是整體壓測的平均耗時卻是 60ms 左右。
每一次都是相同的請求引數，除了訂單號差異。
我們要看為什麼慢，就去找比較慢的操作才行。
目前的很多 ELK 等日誌體系，對於耗時的模糊匹配支援不友好。
找到慢日誌
如果有比較好的工具，直接統計出來。
如果日誌分析工具不夠強大，比如我想找耗時 200-299ms 之間的日誌。
可以使用如下的命令
grep "業務關鍵詞" xxx.log | grep "日誌關鍵詞2" | egrep 'cost=[2][0-9][0-9]' | tail
主要是 egrep 'cost=[2][0-9][0-9]' 正則 grep 可以把耗時 200-299 的日誌找出來，
然後結合日誌，分析整個呼叫鏈路。
慢日誌區間定位
找了幾筆慢的操作，都發現在 log1 和 log2 間隔非常久。
查程式碼，找到 log1 和 log2 的位置，發現是一個 mq 呼叫。
是否是 GC？
發現 CAT 上這個時間存在 young GC，但是 gc 耗時只有 60ms 左右。
但是慢操作的耗時介於 60~400ms 的都有。
所以可以排除是 gc 的問題，而且每一次都是這個位置，gc 不可能每一次都這麼巧。
就算是 gc，那麼慢的時間長度應該一致，而不是波動這麼大。
耗時操作的確認
所以懷疑就是 mq 的問題。
比如 database/cache/rpc/http 這些都值得懷疑。
不過在懷疑之前，我們可以做一些其他因素的排除，比如把本次新增的功能，比如日誌 aop 切面/脫敏等功能全部關閉，排除新的因素影響。
發現關閉之後壓測無變化，所以最後只剩下一個資源問題。
小結
希望本文對你有所幫助，如果喜歡，歡迎點贊收藏轉發一波。
我是老馬，期待與你的下次相遇。