以下文章來源于阿里云開發者，作者譽銘

導讀

分享作者在使用Arthas火焰圖工具進行Java應用性能分析和優化的經驗。

看到標題是不是很多人在想是不是標題黨了，是也不是~，請聽我細細道來~

我們的應用代碼是用Java寫的，因此使用的火焰圖工具是Arthas，下面的分析也是基于此。

Arthas火焰圖使用

啟動火焰圖分析

$ profiler start
Started [cpu] profiling

停止

$ profiler stop --format flamegraph
profiler output file: /tmp/test/arthas-output/20211207-111550.html
OK

如上所示默認會生成一個html的火焰圖文件，指定輸出格式相關可參考官方文檔。

火焰圖示例

火焰圖橫軸代表CPU的占用時間，橫軸越寬代表CPU占用越多，鼠標移動上去也可以看到這個方法究竟占用了多少CPU。

縱軸代表調用棧，火焰越高代表調用棧越深。

其中綠色部分代表Java代碼，黃色部分代表JVM C++代碼，橙色部分代表內核態C語言代碼，紅色代表用戶態C語言代碼。

如何分析火焰圖(附實戰)

事情是這樣的，我們的業務簡單來說就是監聽發貨消息后執行一系列操作，分自動和批量兩種方式，批量的大用戶進行業務操作時，會同時有幾萬單、十幾萬單的產生，相當于大促時的流量了，因此cpu占用總是有尖刺，有時單機甚至能到80+%。而且日常流量時感覺cpu占用和流量數據相比也有些偏高，因此決定使用火焰圖分析下。

從上往下看

下面采用兩個在優化過程中比較典型的兩個案例。

案例一

火焰圖分析最簡單的方式就是找大平頂，如果一個方法占用比較耗時、調用次數很多，那么他的橫軸一定是比較寬的，體現到火焰圖上就是一個大平頂。

圖中紅框是業務代碼的執行，其中藍框是初步定位到的耗時操作，點開后可以看到左側是sentinel采樣CPU占用，占用總CPU3%~4%，這部分應該是不會隨流量上升而升高的， 這次就先沒有動這塊。第二塊是在metaq的消費者代碼里執行的，因此重點關注，因為我們的應用是消息驅動的，接受tp的發貨消息后進行對應的操作，metaq流量升高，這部分對應的操作大概率也是會隨之升高的。

占總CPU占用達到了驚人的9.3%。 點開后可以看到是脫敏工具，其對性能的影響幾乎和發貨消息齊平了，排查后發現是我們部門內部使用的鏈路采集工具，在采集metaq消息時會對消息進行脫敏處理，脫敏工具會對姓名、郵箱、手機號等分別進行正則匹配，而我們接收的交易消息中是包含整個訂單信息的，這個對象是很大的(包含擴展字段等諸多信息)，對其使用正則進行脫敏工作量巨大。正常情況下使用此工具采集線上流量對性能影響不是很大，但是在我們的場景影響有點出乎意料...... 由于我們平時基本不會在鏈路圖上關注消息的內容，一般都是用來看HSF鏈路，因此直接把dp對metaq的采集關閉了。

案例二

使用全局搜索后居然占用了將近6%的CPU，這可是日常的流量下截取的火焰圖，系統流量升高時占用比例會更大。 點開后可以看到是進行HSF調用的時候，獲取Java調用棧比較耗時，之前寫代碼的時候懷疑過獲取調用棧會比較耗性能，但沒想到居然比一次HSF調用本身的耗時都大了。這個地方之前是為了獲取調用來源，打印到日志中方便排查問題的(歷史代碼)，后續將HSF的調用日志改成了通過HSF Filter的方式，去掉了獲取調用棧的邏輯。 其實案例二我一開始不是從上往下看定位到的，因為調用HSF的地方不止一個，每個耗時其實也不長，整體看的話從上往下還是比較難發現的。

從下往上看

案例二

如果從上往下看效果不明顯，可以從我們系統主要流量入口處進行分析，從下面入口一步步往上點，也可以發現問題，帶著懷疑的態度來找，上述的案例二我一開始并沒有注意到上方的問題，我是一步步從消息入口看，然后點到上面發現的這個調用消耗居然比HSF多的。

可以看到這個調用不是集中在一個地方的，細看每個地方都有調用，所以整體對性能的影響才那么大。 全局搜索后可以看到到處都有調用(圖示紫色部分)。

從下往上找更適合細化的時候，專門對某個鏈路進行分析優化。

優化效果

下面來讓我們計算一下數據，來看看樓主是不是標題黨了。

整體大致優化了5~6%左右(7月份的時候，機器數量是30臺，8月縮容到了27臺)，取5%，其中系統CPU占用在6.5%左右，從日常流量上來看，用戶態cpu從26%到21%，下降19%+，考慮縮容的關系，20%的優化大抵是有的。 由于這是日常流量的優化結果，大促流量突增時，系統負載降低應該會更明顯，優化后大用戶批量操作時瞬時流量也基本不會有機器cpu占用超過60%了。 后續雙十一壓測也會繼續關注優化，流量上升后更多問題可能就會暴露出來。