mat（Eclipse Memory Analyzer tool）--heap dump分析

在工作中可能會遇到記憶體溢出這種災難性的問題，那麼程式肯定是存在問題，找出問題至關重要，上一篇文章講了jmap指令的使用方法，當然用jmap導出的檔案我們也看不懂啊，那就交給memory analyzer(mat)這個工具，讓他幫助我們來觀察程式的記憶體分布情況吧。

MAT 不是一個萬能工具，它并不能處理所有類型的堆存儲檔案。但是比較主流的廠家和格式，例如 Sun, HP, SAP 所采用的 HPROF 二進制堆存儲檔案，以及 IBM 的 PHD 堆存儲檔案等都能被很好的解析。下面來看看要怎麼做呢，也許對你有用。
官方文檔：http://help.eclipse.org/luna/index.jsp?topic=/org.eclipse.mat.ui.help/welcome.html
           

造成OutOfMemoryError原因一般有2種：

1、記憶體洩露，對象已經死了，無法通過垃圾收集器進行自動回收，通過找出洩露的代碼位置和原因，才好确定解決方案；

2、記憶體溢出，記憶體中的對象都還必須存活着，這說明Java堆配置設定空間不足，檢查堆設定大小（-Xmx與-Xms），檢查代碼是否存在對象生命周期太長、持有狀态時間過長的情況。

适用JDK1.8的mat工具：https://www.eclipse.org/downloads/download.php?file=/mat/1.8.1/rcp/MemoryAnalyzer-1.8.1.20180910-win32.win32.x86_64.zip

1. 用jmap生成堆資訊

jmap -dump:live,format=b,file=生成jmap堆檔案位址 pid

注意點：

1、18593是我們需要進行jmap的運作程序号，通過Linux的top指令可以擷取到pid

2、進行jmap操作時需要在pid運作的使用者權限下操作

3、file=***的位址必須是pid的使用者具有的通路權限的位址

打開MemoryAnalyzer工具

**2. 将堆資訊導入到mat中分析 **

mat會為我們生多個報告

從上圖可以看到它的大部分功能，在餅圖上,你會發現轉儲的大小和數量的類,對象和類加載器。

正确的下面,餅圖給出了一個印象最大的對象轉儲。移動你的滑鼠一片看到對象中的對象的細節檢查在左邊。下面的Action标簽中：

• Histogram可以列出記憶體中的對象，對象的個數以及大小。
• Dominator Tree可以列出那個線程，以及線程下面的那些對象占用的空間。
• Top consumers通過圖形列出最大的object。
• Leak Suspects通過MA自動分析洩漏的原因。

  

  Class Name ： 類名稱，java類名

  Objects ： 類的對象的數量，這個對象被建立了多少個

  Shallow Heap ：一個對象記憶體的消耗大小，不包含對其他對象的引用

  Retained Heap ：是shallow Heap的總和，也就是該對象被GC之後所能回收到記憶體的總和

一般來說,Shallow Heap堆中的對象是它的大小和保留記憶體大小相同的對象是堆記憶體的數量時,将釋放對象被垃圾收集。

保留設定一組主要的對象,例如一個特定類的所有對象,或所有對象的一個特定的類裝入器裝入的類或者隻是一群任意對象,是釋放的組對象如果所有對象的主要設定變得難以接近的。保留設定包括這些對象以及所有其他對象隻能通過這些對象。保留大小是總堆大小中包含的所有對象的保留。摘自eclipse

關于的詳細講解，建議大家檢視Shallow heap & Retained heap，這是個很重要的概念。

這兒借助工具提供的regex正則搜尋一下我們自己的類，排序後看看哪些相對是占用比較大的。

左邊可以看到類的詳細使用，比如所屬包，父類是誰，所屬的類加載器，記憶體位址，占用大小和回收情況等

這兒有個工具可以根據自己的需求分組查找，預設根據class分組，類似我們sql裡的group by了~~

這裡可以看到上面3個選項，分别生成overview、leak suspects、top components資料，但是這兒生成的不是圖表，如果要看圖表在（Overview）中的Action标簽裡點選檢視。

這個是Overview中的 Heap Dump Overview視圖，從工具欄中點開，這是一個全局的記憶體占用資訊

然後可以點開SystemProperties和Thread Overview進行檢視，我這裡就不貼了内容比較多。

Dominator Tree

我們可以看到ibatis占了較多記憶體

Top consumers

按等級分布的類使用情況，其實也就是按使用次數檢視，java.lang.Class被排在第一

還有一張圖是我們比較關心的，那就是按包名看占用，根據包我們知道哪些公共用的到jar或自己的包占用

這樣就可以看到包和包中哪些類的占用比較高。

從這份報告，看到該圖深色區域被懷疑有記憶體洩漏，可以發現整個heap隻有79.7M記憶體，深色區域就占了62%。是以，MAT通過簡單的報告就說明了項目是有可疑代碼的，具體點開詳情來找到類，

點選滑鼠，在List Objects-> with outgoing references下可以檢視該類都引用了什麼對象，由此檢視是否因為其他對象導緻的記憶體問題。

下面繼續檢視pool的gc ROOT

如下圖所示的上下文菜單中選擇 Path To GC Roots -> exclude weak references, 過濾掉弱引用，因為在這裡弱引用不是引起問題的關鍵。

進入檢視即可，我這兒的代碼沒有問題，就不用貼了。

The classloader/component “org.apache.catalina.loader.WebappClassLoader @ 0xa34cde8” occupies 19,052,864 (22.80%) bytes. The memory is accumulated in one instance of “java.util.HashMap$Entry[]” loaded by “”.

Keywords

java.util.HashMap$Entry[]

org.apache.catalina.loader.WebappClassLoader @ 0xa34cde8

這段話是在工具中提示的，他告訴我們WebappClassLoader占了19,052,864 位元組的容量，這是tomcat的類加載器，JDK自帶的系統類加載器中占用比較多的是HashMap。這個其實比較正常，大家經常用map作為存儲容器。

除了在上一頁看到的描述外，還有Shortest Paths To the Accumulation Point和Accumulated Objects部分，這裡說明了從GC root到聚集點的最短路徑，以及完整的reference chain。觀察Accumulated Objects部分，java.util.HashMap的retained heap(size)最大，是以明顯類執行個體都聚集在HashMap中了。

來看看Accumulated Objects by Class區域，這裡能找到被聚集的對象執行個體的類名。java.util.HashMap類上頭條了，被執行個體化了5573次，從這兒看出這個程式不存在什麼問題，因為這個數字是比較正常的，但是當出問題的時候我們都會看到比較大的自定義類會在前面，而且占用是相當高。

當然，mat這個工具還有很多的用法，這裡把我了解的分享給大家，不管如何，最終我們需要得出系統的記憶體占用，然後對其進行代碼或架構，伺服器的優化措施！