性能調優工具-火焰圖

前言

---

工具的進化一直是人類生產力進步的標誌，合理使用工具能大大提升咱們的工做效率，遇到問題時，合理使用工具更能加快問題排查的進度。這也是我爲何很是喜歡 shell 的緣由，它豐富的命令行工具集加管道特性處理起文本數據集來真的精準而優雅，讓人迷醉。

但不少時候文本的表現力很是有限，能夠說匱乏，表達絕對值時，天然是無往不利，但在展現相對值時，就有些捉襟見肘了，就更不用說多維數據了。咱們用 shell 能夠很是快速地查詢出文本內的累加值、最大值等，但一遇到兩組值的相關性分析時，就一籌莫展了。這個時候，就須要使用另外一種分析工具 – 圖了，如散點圖就能很清晰地展現相關性。

今天就準備介紹一種圖，火焰圖，以前組內大神分享過它的使用辦法，但我以後好久都沒有用過，以致於對它沒有什麼深入印象，最近排查咱們 Java 應用負載問題時試用了一下，這纔對它的用途有了點心得。

轉載隨意，文章會持續修訂，請註明來源地址：https://zhenbianshu.github.io 。

介紹

---

引子

在排查性能問題時，咱們一般會把線程棧 dump 出來，而後使用 grep --no-group-separator -A 1 java.lang.Thread.State jstack.log | awk 'NR%2==0' | sort | uniq -c | sort -nr 相似的 shell 語句，查看大多數線程棧都在幹什麼。而由線程棧的出現頻率，來推斷 JVM 內耗時最多的調用。

至於其原理，設想廣場上有一個大屏幕在不停地播放各類廣告。若是咱們隨機對大屏幕拍照，次數多了，統計照片中各個廣告出現的頻率，基本能夠得出每一個廣告的播放時長佔比了。而咱們應用的資源就像大屏幕，每次調用就像是播放一次廣告，統計 dump 出的線程棧出現比例，也就基本能看出線程棧的耗時佔比，雖然有偏差，可是屢次統計下應該差不了多少。這也就是爲何有些家長每次進孩子房間都發現孩子在看系統桌面後覺得孩子平時喜歡對着桌面發呆的緣由。 :)

2444 	at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1200) 1587 at sun.misc.Unsafe.park(Native Method) 795 at java.security.Provider.getService(Provider.java:1035) 293 at java.lang.Object.wait(Native Method) 292 at java.lang.Thread.sleep(Native Method) 73 at org.apache.logging.log4j.core.layout.TextEncoderHelper.copyDataToDestination(TextEncoderHelper.java:61) 71 at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) 70 at java.lang.Class.forName0(Native Method) 54 at org.apache.logging.log4j.core.appender.rolling.RollingFileManager.checkRollover(RollingFileManager.java:217) 

可是這樣有些問題，首先寫 shell 挺費事的，另外若是我想查看自棧頂第二個棧的最多調用，即便修改了 shell 命令，結果也不直觀。

產生這個問題的主要緣由是，咱們的線程棧是有調用關係的，即咱們須要考慮線程棧的 調用鏈 和 出現頻率 兩個維度，而單一的文本表現這兩種維度比較困難，因此，著名性能分析大師 brendan gregg 就提出了火焰圖。

介紹

火焰圖，因其形似火焰而得名，其開源代碼地址在 Github-brendangregg-Flamegraph。

它是一種 svg 可交互式圖形，咱們經過點擊和鼠標指向能夠展現出更多的信息。下圖就是一個典型的火焰圖，從結構上，它是由多個大小和顏色各異的方塊構成，每一個方塊上都有字符，它們底部鏈接在一塊，組成火焰的基底，頂部分出許多」小火苗」。

當咱們點擊方塊時，圖片會從咱們點擊的方塊爲基底向上展開，而咱們鼠標指向方塊時，會展現出方塊的詳細說明。

特性

介紹火焰圖的分析前，咱們要首先說明它的特性：

• 由底部到頂部能夠追溯一個惟一的調用鏈，下面的方塊是上面方塊的父調用。
• 同一父調用的方塊從左到右以字母序排列。
• 方塊上的字符表示一個調用名稱，括號內是火焰圖指向的調用在火焰圖中出現的次數和這個方塊佔最底層方塊的寬度百分比。
• 方塊的顏色沒有實際意義，相鄰方塊的顏色差只爲了便於查看。

分析

那麼，給咱們一張火焰圖，咱們怎麼能看出系統哪裏有問題呢？

由上文中的火焰圖特性特性，查看火焰圖時，咱們最主要的關注點要放在方塊的寬度上，由於寬度表明了調用棧在全局出現的次數，次數表明着出現頻率，而頻率也就能夠說明耗時。

可是觀察火焰圖底部或中部方塊的寬度佔比意義不大，如上面的火焰圖，中部的 do_redirections 函數寬度是 24.87%，也就是說它耗用了整個應用近四分之一的時間，可是真正消耗時間的並非 do_redirections 函數，而是 do_redirections 內部又調用的其餘函數，而它的子調用分爲了不少個，每一個調用的耗時並無異常。

咱們更應該關注的是火焰圖頂部的一些 「平頂山」，頂部說明它沒有子調用，方塊寬說明它耗時長，長時間 hang 住，或者被很是頻率地調用，這種方塊指向的調用纔是性能問題的罪魁禍首。

找到了異常調用，直接優化它，或者再根據火焰圖的調用鏈層層向下，找到咱們的業務代碼進行優化，也就大功告成。

應用場景

每種工具都有其適合的應用場景，火焰圖則適合用在：

• 代碼循環分析：若是代碼中有很大的循環或死循環代碼，那麼從火焰圖的頂部或接近項部的地方會有很明顯的」平頂」，表示代碼頻繁地在某個線程棧上下切換。但須要注意的是，若是循環的總耗時不長，在火焰圖上不會很明顯。
• IO 瓶頸/鎖分析：在咱們的應用代碼中，咱們的調用廣泛都是同步的，也就是說在進行網絡調用、文件 I/O 操做或未成功得到鎖時，線程會停留在某個調用上等待 I/O 響應或鎖，若是這個等待很是耗時，會致使線程在某個調用上一直 hang 住，這在火焰圖上表現得會很是清晰。 與此相對的是，咱們應用線程構成的火焰圖沒法準確地表達 CPU 的消耗，由於應用線程內沒有系統的調用棧，在應用線程棧 hang 住時，CPU 可能去作其餘事了，致使咱們看到耗時很長，而 CPU 卻很閒。
• 火焰圖倒置分析全局代碼：火焰圖倒置有時也會很實用，若是咱們的代碼 N 個不一樣的分支都調用某一方法，倒置後，全部棧頂相同的調用被合併在一塊，咱們就能看出這個方法的總耗時，也就很容易評估出優化這個方法的收益。

實現

---

既然火焰圖這麼強大，那麼咱們該怎麼實現呢？

生成工具

brendan gregg 大神已經把生成火焰圖的方法用 perl 實現了，開源代碼就在上文的 Github 倉庫中，根目錄下的 flamegraph.pl 文件就是可執行的 perl 文件了。

這個命令還能夠傳入各類參數，支持咱們修改火焰圖的顏色、大小等 。

但 flamegraph.pl 只能處理特定格式的文件，像：

a;b;c 12
a;d 3
b;c 3
z;d 5
a;c;e 3

前面是調用鏈，每一個調用之間用 ; 隔開，每行後面的數字是調用棧出現的次數。

如上面的數據，用 flamegraph.pl 生成的火焰圖以下圖：

數據準備

至於咱們的 jstack 信息如何被處理成上面的格式，大神則爲常見的 dump 格式都提供了工具，像 stackcollapse-perf.pl能夠處理 perf 命令的輸出，stackcollapse-jstack.pl 處理 jstack 輸出，stackcollapse-gdb.pl 處理 gdb 輸出的棧等。

也能夠用 shell 簡單地實現一下 jstack 的處理方式：

grep -v -P '.+prio=\d+ os_prio=\d+' | grep -v -E 'locked <' | awk '{if ($0==""){print $0}else{printf"%s;",$0}}' | sort | uniq -c | awk '{a=$1;$1="";print $0,a}'

小結

---

火焰圖總結完了，之後再遇到性能問題又多了一種應對方式。

作開發越久，越能感覺獲得工具的重要性，因此我準備加一個專題來專門介紹我使用的各類工具。固然，這也就更須要我更多地瞭解、使用和總結新的工具了。

關於本文有什麼疑問能夠在下面留言交流，若是您以爲本文對您有幫助，歡迎關注個人 微博 或 GitHub 。您也能夠在個人 博客REPO 右上角點擊 Watch 並選擇 Releases only 項來 訂閱 個人博客，有新文章發佈會第一時間通知您。