java取得到heapdump檔案後怎麼快速分析

heapdump檔案介紹

heap dump： heap dump檔案是一個二進位文件，它保存了某一時刻JVM堆中物件使用情況。 HeapDump檔案是指定時刻的Java堆疊的快照，是一種鏡像檔。

產生heap dump(記憶體溢位)錯誤原因一般出於以下原因：

1)JVM記憶體過小，

2)程式不嚴密，

3)產生過多的垃圾無法回收。

簡介

在先前的OOM問題複盤之後，本週，又一Java服務出現了記憶體問題，這次問題不嚴重，只會觸發堆記憶體佔用高警報，沒有觸發OOM，但好在先前的複盤中總結了dump腳本，會在堆佔用高時自動執行jstack與jmap，使得我們成功保留了問題現場。

查看堆佔用分佈

發現有heapdump檔案後，我立刻拷貝到本機，並使用MAT分析，如下：

很顯然，好像是什麼介面分配了非常大的String對象，一個String物件約200MB，那它是哪分配的呢？

查找大物件分配執行緒

這個分配行為一定是某個執行緒做的，而執行緒是最常見的GC Root，因此只要找尋物件的GC Root即可，如下：

找到了大物件對應的分配執行緒是http-nio-8088-exec-6，如下：

##查看線程棧

如何查看這個線程在做什麼？在MAT中摸索了一會，沒找到相關內容，回想起我們的dump腳本中記錄了jstack，打開看看，如下：

##可以發現，這個線程正在做json序列化，但我仔細找了好一會兒，也沒有找到相關介面的Controller，這是因為線程已經執行完了Controller裡面的邏輯，之後返回介面回應資料時分配的大物件。

可是，執行緒堆疊中沒有業務程式碼，就沒辦法定位是哪個介面有問題了。 。 。

檢查accesslog日誌

考慮到分配大物件的介面肯定會很慢，於是我轉向查看tomcat的accesslog日誌，如下：

終於，找到了問題接口，這個接口是用來查詢商品數據的，當輸入3時會查詢出所有3開頭的商品，而這有20w 數據，解決問題很簡單，加個limit完事。

排查過程複盤

然而，我一直有個習慣，就是解決一個問題後，我會反思一下問題解決過程中有多少運氣成分。

如果你經常閱讀排查問題類的技術文章，你會發現不少文章，中間突然有一步定位到了問題根因，可能是突然發現了一個線索，或是硬看代碼看出來的，或是猜測某處有問題，我覺得這種排查過程都有不少運氣成分，我希望問題是透過多年理論基礎的積累和對診斷工具的熟練使用，而有章法的一步步查出來的。

而上面透過accesslog能夠定位到問題，有一定的運氣成分，因為本次記憶體問題不極端，如果此介面請求量大，那就會瞬間觸發多次FGC，進而影響其它接口也變慢，進而無法分辨出哪個是導致問題的介面！

我想，從理論上來說，Java堆文件裡面，應該有線程棧以及線程棧上的參數，因為線程是對象，參數也是對象，它們理應都在堆裡，於是我找了個空閒時間，又摸索MAT這個工具了。

MAT查看線程棧

摸索了一會，我就發現有這樣一個按鈕，可以查看線程信息，如下：

#找到前面說的執行緒http-nio-8088-exec-6，展開後，就可以發現執行緒堆疊以及堆疊上的參數，如下：

##這就找到了請求的Request參數對象，再將Request對像多次展開後，就可以找到接口url訊息，如下：

VisualVM查看線程棧

考慮到不少同學習慣用VisualVM分析heapdump，這裡也放一下VisualVM的使用方法。

首先，載入heapdump文件，如下：

然後選擇對應對象，右鍵選擇Select in Threads，如下：

定位到線程堆疊後，找到要查看的Request對象，點選進入，如下：

同樣，展開Request對象後，可找到url訊息，如下：

以上是java取得到heapdump檔案後怎麼快速分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！