背景
相信有不少人遇到過線上業(yè)務(wù)出現(xiàn)問題，為排查導(dǎo)出線上業(yè)務(wù)堆棧，但是最后發(fā)現(xiàn)導(dǎo)出的堆棧文件過大，少則2-3G，多則10GB大小，無法直接分析，這時候有點束手無策。本期的文章，就以如上描述的場景為例子，簡單介紹下對于超大的堆棧，如何進行堆棧分析，獲得
我們需要的現(xiàn)場數(shù)據(jù)。
分析
導(dǎo)出堆棧
添加啟動參數(shù)，在內(nèi)存溢出時導(dǎo)出
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=xxx.hprof
手動導(dǎo)出
jmap -dump:live,format=b,file=xxx.hprof <PID>
分析堆棧
常見的分析工具有如下的幾種：
- jvisualvm
這個是JDK自帶的工具，可以通過圖形化界面查看，可以在jdk的bin目錄下找到。但是這個工具只適合較小堆棧分析。 - jhat
可以通過jhat -J-Xmx5120m xxx.hprof來進行分析，執(zhí)行后會產(chǎn)生一個Web服務(wù)，然后可以通過這個web服務(wù)查看具體的堆棧情況。但是經(jīng)過實際測試，在本地的堆棧是4GB大小的時候，依然無法打開，會報OOM錯誤。
在找了內(nèi)存為32G的機器后，可以執(zhí)行成功，但是堆棧分析中histogram部分依然無法打開。因此，這種，在面對超大的堆棧的時候，依然無法滿足我們的需求。 - eclipse MAT
這里分兩部分，對于較小的堆棧，可以使用其圖形化界面的軟件直接分析，而重點是對大堆棧的分析過程。
在下載該軟件，解壓完成后?？梢栽趫?zhí)行目錄發(fā)現(xiàn)MemoryAnalyzer.ini，可以修改其中的配置，增大內(nèi)存配置。根據(jù)實際使用的經(jīng)驗，和要分析的堆棧大小差不多即可以。
然后執(zhí)行如下的命令:
./ParseHeapDump.sh xxx.hprof org.eclipse.mat.api:suspects org.eclipse.mat.api:overview org.eclipse.mat.api:top_components
如果堆棧較大，這個執(zhí)行時間會比較長，實際使用約4G的堆棧，執(zhí)行實際在5分鐘左右。完成后會得到一些文件，其中包括三個ZIP格式的分析報告，分別是m_Leak_Suspects.zip, m_System_Overview.zip, m_Top_Components.zip
解壓后就可以獲得對應(yīng)的分析報告，然后可以使用瀏覽器直接打開里邊的index.html瀏覽。
image.png
因本次分析未保存圖片以及部分數(shù)據(jù)不適宜公開，使用https://www.codenong.com/cs106586557的實例圖片
這個分析報告也可以用MAT打開。
總結(jié)
以上就是本期的內(nèi)容，最后提兩點。一個是日常應(yīng)該盡量避免配置大堆棧，這種一旦出現(xiàn)問題還是不好分析的，像業(yè)務(wù)應(yīng)用這種，如果采用容器的集群部署，一方面能優(yōu)化資源使用，一方面也能避免大堆棧，降低運維成本。第二點呢，堆棧分析屬于事后分析，如果能提供足夠的日志和監(jiān)控告警，提前發(fā)現(xiàn)問題，或許就能減少因意外故障造成的損失。
