heapdump文件介紹

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

產生heap dump(內存溢出)錯誤原因一般出于以下原因：

1)JVM內存過小，

2)程序不嚴密，

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

簡介

在之前的OOM問題復盤之后，本周，又一Java服務出現(xiàn)了內存問題，這次問題不嚴重，只會觸發(fā)堆內存占用高報警，沒有觸發(fā)OOM，但好在之前的復盤中總結了dump腳本，會在堆占用高時自動執(zhí)行jstack與jmap，使得我們成功保留了問題現(xiàn)場。

查看堆占用分布

發(fā)現(xiàn)有heapdump文件后，我立馬拷貝到本機，并使用MAT分析，如下：

很顯然，好像是什么接口分配了非常大的String對象，一個String對象約200MB，那它是哪分配的呢？

查找大對象分配線程

這個分配行為肯定是某個線程做的，而線程是最常見的GC Root，因此只要查找對象的GC Root即可，如下：

找到了大對象對應的分配線程是http-nio-8088-exec-6，如下：

查看線程棧

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

可以發(fā)現(xiàn)，這個線程正在做json序列化，但我仔細找了好一會，也沒有找到相關接口的Controller，這是因為線程已經執(zhí)行完了Controller里面的邏輯，之后返回接口響應數據時分配的大對象。

可是，線程棧中沒有業(yè)務代碼，就沒法定位是哪個接口有問題了。。。

檢查accesslog日志

考慮到分配大對象的接口肯定會很慢，于是我轉向查看tomcat的accesslog日志，如下：

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

排查過程復盤

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

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

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

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

MAT查看線程棧

摸索了一會，我就發(fā)現(xiàn)有這樣一個按鈕，可以查看線程信息，如下：

找到前面說的線程http-nio-8088-exec-6，展開后，就可以發(fā)現(xiàn)線程棧以及棧上的參數，如下：

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

嗯，這樣分析heapdump文件真tm的高效啊??

MAT下載地址：https://www.eclipse.org/mat/downloads.php

VisualVM查看線程棧

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

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

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

定位到線程棧后，找到要查看的Request對象，點擊進入，如下：

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

VisualVM下載地址：https://visualvm.github.io/download.html

總結

雖然我也用MAT很多次了，但每次問題都太簡單，以至于沒有深入使用過MAT，導致到現(xiàn)在才知道有如此便捷的分析路徑。

參考資料

一次線上OOM問題的個人復盤
jmap執(zhí)行失敗了，怎么獲取heapdump？

到此這篇關于java獲取到heapdump文件后，如何快速分析？的文章就介紹到這了,更多相關java分析heapdump文件內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論