Eclipse MAT安裝(有時候dump下來的.hprof文件太大,用eclipse解析不了,就要用獨立版的MAT來解析了,不過獨立版默認也無法解析太大的文件,這就要我們手動給MAT分配更大的內存給它使用了
)
有時候dump下來的.hprof文件太大,用eclipse解析不了,就要用獨立版的MAT來解析了,不過獨立版默認也無法解析太大的文件,這就要我們手動給MAT分配更大的內存給它使用了。如下圖,打開箭頭指向的文件,
T使用
導入
File -> Import -> Other -> Heap Dump 然后選擇Dump文件的路徑,選擇文件進行導入
界面
- Histogram可以列出內存中的對象,對象的個數以及大小。
- Dominator Tree可以列出那個線程,以及線程下面的那些對象占用的空間。
- Top consumers通過圖形列出最大的object。
- Leak Suspects通過MA自動分析泄漏的原因。
名詞解釋
-
Shallow Size :對象自身占用的內存大小,不包括它引用的對象。
針對非數組類型的對象,它的大小就是對象與它所有的成員變量大小的總和。當然這里面還會包括一些java語言特性的數據存儲單元。
針對數組類型的對象,它的大小是數組元素對象的大小總和。 -
Retained Size :當前對象大小+當前對象可直接或間接引用到的對象的大小總和。(間接引用的含義:A->B->C, C就是間接引用)
換句話說,Retained Size就是當前對象被GC后,從Heap上總共能釋放掉的內存。
不過,釋放的時候還要排除被GC Roots直接或間接引用的對象。他們暫時不會被被當做Garbage。
OOM解決思路
- 只要有溢出,時間久了,溢出類的實例數量或者其占有的內存會越來越多,排名也就越來越前,通過多次對比不同時間點下的Histogram圖對比就能很容易把溢出類找出來。
- 通 過Histogram視圖或者Dominator Tree視圖,找到疑似溢出的對象或者類后,選擇Path to GC Roots或者Merge Shortest Paths to GC Roots,這里有很多過濾選項,一般來講可以選擇exclude all plantom/weak/soft etc. references。這樣就排除了虛引用、弱引用、以及軟引用,剩下的就是強引用。從GC上說,除了強引用外,其他的引用在JVM需要的情況下是都可以 被GC掉的,如果一個對象始終無法被GC,就是因為強引用的存在,從而導致在GC的過程中一直得不到回收,因此就內存溢出了。
- 接下來就需要直接定位具體的代碼,看看如何釋放這些不該存在的對象,比如是否被cache住了,還是其他什么原因。
- 找到原因,清理干凈后,再對照之前的操作,看看對象是否還再持續增長,如果不在,那就說明這個溢出點被成功的堵住了。
- 最后用jstat跟蹤一段時間,看看Old和Perm區的內存是否最終穩定在一個范圍內,如果長時間穩定在一個范圍,那溢出的問題就解決了,如果還再繼續增長,那繼續用上述方法,看看是否存在其他代碼的溢出點,繼續找出,將其堵住。
說明參考:
https://www.cnblogs.com/loong-hon/p/10475143.html
測試參考:
https://blog.csdn.net/wuzhangweiss/article/details/78334711