在日常工作中經常會遇到系統應用出現full gc、cpu內存飆高等場景，如果想要快速解決這些線上問題就需要首先能快速定位，最好能定位到具體代碼。本文旨在通過一款線上監控診斷產品，阿里巴巴的arthas（阿爾薩斯）內部集成的火焰圖工具async-profiler結合自身系統應用中的使用，方便我們能夠快速定位線上問題。
一、背景
1、在訂單域任務系統，master機器和slaver機器頻繁出現full gc和cpu間歇性升高的現象，young GC也出現平均1分鐘10次。master機器線程也增加到1500左右。系統應用採用的是CMS垃圾回收器，4c8g分配堆內存大小4G。但是堆內存和非堆內存正常。
2、隨着時間推移，full gc從每隔20分鐘一次變成 每個5分鐘或者3分鐘一次，stop the world。FULL GC 和 Young GC 不正常，如下圖。
堆內存和非堆內存正常。
CPU一分鐘一次達到高點，部分機器達到75%以上。線程，在上午超過1400，重啓後正常。
系統穩定性受到挑戰，需要儘快排查出問題所在。
二、工具選型及實踐
市面上很多排查工具，怎樣才能快速排查出問題。結合arthas、async-profiler火焰圖（採樣）、visualVM（跨時間dump文件對比）、gceasy這四種工具，都進行實戰對比。
1、arthas分析
下圖分析master機器是反序列化商品域渠道配置接口對象耗CPU
下圖也發現反查快手任務也會引起高cpu。分析這臺機器既是master，又是slaver。slaver會執行反查快手任務。
2、visualVM分析
dump兩個文件，跨時一天，進行對比。
啓動visualVM
cd /Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/bin
jvisualvm
/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/lib/visualvm目錄下 visualvm.conf修改內存空間大小
對比發現，最大是查詢ES的數據，反序列化對象並不是最大，但是也能在dump文件中查找到。因爲arthas查的是CPU和線程，dump文件是內存，所以不完全一致。
一次500個
3、gceasy分析
修改jvm，-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:./gc.log，打印gc日誌。
通過gceasy.io線上對比工具，沒有內存泄露，但是也未發現gc產生的具體原因。
4、async-profiler火焰圖
從上圖，看到主要分爲兩大部分，左邊的反查快手任務（因master機器，既是master，也是slaver），右邊是掃描es裏面代扣任務的反序列化對象佔用很大比重。和arthas分析的一樣。
下載內存火焰圖，可以看到左邊也是快手反查，右邊則是查詢ES（包含反序列化對象）。和dump文件比較能覈對上。
三、修復上線
根據上述四種工具的排查過程，可以明顯看到使用arthas集成的async-profiler更直觀和方便，便於定位問題。在修改對應的代碼後，上線進行後續觀察系統穩定正常。
四、使用步驟
async-profiler 火焰圖。
1、申請堡壘機（root權限）
2、登陸以後下載 最新的jar包 wget https://alibaba.github.io/arthas/arthas-boot.jar
3、安裝（admin權限 cd）java -jar arthas-boot.jar
4、查看cpu耗時、dashboard(q命令表示退出)、thread
5、profiler start 啓動火焰圖工具進行採樣
https://jlynet.github.io/2021/08/07/Java%E8%AF%8A%E6%96%AD%E5%B7%A5%E5%85%B7Arthas%E9%AB%98%E7%BA%A7%E5%91%BD%E4%BB%A4%E6%95%99%E7%A8%8B/Arthasprofiler%E5%91%BD%E4%BB%A4/profiler getSamples
profiler status
profiler stop --format html。生成火焰圖
6、下載火焰圖
7、多種維度：
lock 鎖對象\alloc 內存\默認cpu
8、效果
CPU\內存等不同的火焰圖
9、其他
還可以反編譯jar包的代碼
統計方法調用時間
以上。本文旨在通過具體的場景運用和實操，介紹arthas火焰圖如何在系統中快速定位問題，歡迎感興趣的同事一起學習探討。
五、參考資料
https://gceasy.io/diamondgc-report.jsp?oTxnId_value=e8692cc6-f79d-467c-8e90-6aa96f1b429d
https://blog.csdn.net/lkx444368875/article/details/104906673