Eclipse Memory Analyzer Tool（MAT）是一個強大的基於Eclipse的內存分析工具，可以幫助我們找到內存泄露，減少內存消耗。

工作中經常會遇到一些內存溢出、內存泄露等問題，同時還可能導致CPU使用率也很高，因爲在頻繁的進行GC垃圾回收，這時候就需要分析導致問題的原因，MAT是一個比較好用的工具，但剛開始使用時對於其提供的一些功能還是不太瞭解，故在此總結一下個人覺得比較有用的一些MAT相關概念，其它功能暫時還未用到或者還沒有理解使用方法，後續再補充。

以下是本文的目錄大綱：

視圖 & 功能

1、Overview

2、Histogram視圖

3、Dominator Tree（支配樹）視圖

4、Group分組功能

5、Thread Overview

6、List objects

7、Paths to GC Roots（從對象到GC Roots的路徑） & Merge Shortest Paths to GC roots（從GC Roots到對象的共同路徑）

8、Leak Suspects Report（內存泄露報告）

若有不正之處請多多諒解，歡迎批評指正、互相討論。

請尊重作者勞動成果，轉載請標明原文鏈接：

http://www.cnblogs.com/trust-freedom/p/6744948.html

視圖 & 功能

1、Overview

通過 File > Open Heap Dump... 打開dump文件，最先展示就是Overview概述界面，可以對Heap Dump有一個大致的瞭解，並提供了一些視圖、報告的入口，這些視圖、報告都對分析Heap Dump很有幫助，後續會介紹。

鼠標移動到餅圖某個區域上方，在左側會看到對象的詳細信息，如左上方的 Inspector 展示瞭如：對象hashcode、類名、包名、Class類對象、父類、類加載器、shallow size、retained size、GC root類型。左下方展示了對象的一些屬性信息、類層級信息。

2、Histogram視圖

以下方式可以打開Histogram柱狀圖：

（1）點擊Overview頁面Actions區域內的“Histogram視圖”鏈接

（2）點擊工具欄的“histogram按鈕”

Histogram視圖：

該視圖以Class類的維度展示每個Class類的實例存在的個數、佔用的 [Shallow內存] 和 [Retained內存] 大小，可以分別排序顯示。

從Histogram視圖可以看出，哪個Class類的對象實例數量比較多，以及佔用的內存比較大，Shallow Heap與Retained Heap的區別會在後面的概念介紹中說明。

不過，多數情況下，在Histogram視圖看到實例對象數量比較多的類都是一些基礎類型，如char[]（因爲其構成了String）、String、byte[]，所以僅從這些是無法判斷出具體導致內存泄露的類或者方法的，可以使用 List objects 或 Merge Shortest Paths to GC roots 等功能繼續鑽取數據。如果Histogram視圖展示的數量多的實例對象不是基礎類型，是有嫌疑的某個類，如項目代碼中的bean類型，那麼就要重點關注了。

3、Dominator Tree（支配樹）視圖

以下方式可以打開Dominator Tree視圖：

（1）點擊Overview頁面Actions區域內的“Dominator Tree視圖”鏈接

（2）點擊工具欄的“Dominator Tree按鈕” ，爲整個堆打開一個支配樹視圖

Dominator Tree（支配樹）視圖：

該視圖以實例對象的維度展示當前堆內存中Retained Heap佔用最大的對象，以及依賴這些對象存活的對象的樹狀結構

視圖中展示了實例對象名、Shallow Heap大小、Retained Heap大小、以及當前對象的Retained Heap在整個堆中的佔比

點開Dominator Tree實例對象左側的“+”，會展示出下一層（next level），當所有引用了當前實例對象的引用都被清除後，下一層列出的objects就會被垃圾回收

這也闡明瞭“支配”的含義：父節點的回收會導致子節點也被回收，即因爲父節點的存在使得子節點存活

Dominator Tree支配樹可以很方便的找出佔用Retained Heap內存最多的幾個對象，並表示出某些objects的是因爲哪些objects的原因而存活，在之後的 Dominator Tree概念 部分會對支配樹做更詳細的說明和舉例

4、Group分組功能

使用Group分組功能的方法是，在 Histogram視圖和 Domiantor Tree視圖時，點擊工具欄的 Group result by...

可以選擇以另一種分組方式顯示（默認是No Grouping(objects)，即以對象維度分組）

例如在Histogram視圖或 Dominator Tree視圖，選擇Group by package，可以更好地查看具體是哪個包裏的類佔用內存大，也很容易定位到自己的應用程序

5、Thread Overview

Thread視圖的入口，在工具欄上：

Thread Overview：

在Thread Overview視圖可以看到：線程對象/線程棧信息、線程名、Shallow Heap、Retained Heap、類加載器、是否Daemon線程等信息

在分析內存Dump的MAT中還可以看到線程棧信息，這本身就是一個強大的功能，類似於jstack命令的效果

而且還能結合內存Dump分析，看到線程棧幀中的本地變量，在左下方的對象屬性區域還能看到本地變量的屬性，真的很方便

public class TestThreadOverview {

private String str1 = "str1";

private String str2 = "str2";

public static void main(String[] args) {

TestThreadOverview test = new TestThreadOverview();

String local_str = "local_str";

LockSupport.park();

}

在上面代碼的Heap Dump分析中，可以看到線程調用棧的信息，以及main線程的本地變量TestThreadOverview 和字符串local_str 的信息

上圖中第一個框起來的部分是 new TestThreadOverview()對象（代碼第6行），TestThreadOverview對象有兩個屬性str1、str2

第二個框起來的部分是main方法中的字符串變量local_str（代碼第8行）

結合左側的對象屬性區域，可以更方便的看清線程中對象的具體情況

6、List objects

在 Histogram 或 Dominator Tree視圖，想要看某個條目（對象/類）的引用關係圖，可以使用 List objects 功能

（1）選擇一個條目後，點擊工具欄的 Query Browser > List objects，選擇 with outgoing references 或 with incoming references

（2）直接在某個條目上點擊右鍵，也可以選擇到List object

List objects --> with outgoing references ：查看當前對象持有的外部對象引用（在對象關係圖中爲從當前對象指向外的箭頭）

List objects --> with incoming references ：查看當前對象被哪些外部對象所引用（在對象關係圖中爲指向當前對象的箭頭）

例如上面Thread Overview的例子代碼中，查看main方法中第6行中的

TestThreadOverview test = new TestThreadOverview();

outgoing references查詢結果爲：

可以看到TestThreadOverview對象存在3個引用，第一個是TestThreadOverview的Class類對象，因爲所有Java類都繼承自java.lang.Object，所以都有class對象的引用，後兩個是成員變量str1、str2

即列出了當前main方法中的局部變量TestThreadOverview所持有的所有外部對象引用

incoming references查詢結果爲：

可以看到TestThreadOverview是main線程的一個本地局部變量，main線程本身還是一個GC root，而main線程在某個ThreadGroup中

7、Paths to GC Roots（從對象到GC Roots的路徑） & Merge Shortest Paths to GC roots（從GC Roots到對象的共同路徑）

Paths to GC Roots ：從當前對象到GC roots的路徑，這個路徑解釋了爲什麼當前對象還能存活，對分析內存泄露很有幫助，這個查詢只能針對單個對象使用

Merge Shortest Paths to GC roots ：從GC roots到一個或一組對象的公共路徑

Path to GC roots 和 Merge shortest Paths to GC roots 這兩個查詢都有很多選項，如：

意思是在查詢到GC root的路徑時，是包含所有引用，還是排除一些類型的引用（如軟引用、弱引用、虛引用），從GC角度說，一個對象無法被GC，一定是因爲有強引用存在，其它引用類型在GC需要的情況下都是可以被GC掉的，所以可以使用 exclude all phantom/weak/soft etc. references 只查看GC路徑上的強引用

Path to GC roots 和 Merge shortest Paths to GC roots 的入口和 List objects一樣，可以從工具欄的 Query Browser 進入，或者在條目上直接點擊右鍵進入

需要注意的是，Paths to GC roots是針對單個對象的，故在Histogram視圖無法使用，因爲Histogram視圖是針對類的，只能使用Merge shortest Paths to GC roots查詢

8、Leak Suspects Report（內存泄露報告）

使用MAT打開一個Dump文件時，會彈出嚮導窗口，保持默認選項，點Finish，就會導向 Leak Suspects內存泄露報告頁面

如果打開Dump時跳過了的話，也可以從其它入口進入，如

（1）工具欄上的 Run Expect System Test > Leak Suspects

（2）Overview頁面的Reports部分

Leak Suspects 是MAT幫我們分析的可能有內存泄露嫌疑的地方，可以體現出哪些對象被保持在內存中，以及爲什麼它們沒有被垃圾回收

MAT提供了一個很貼心的功能，將報告的內容壓縮打包到一個zip文件，並放在原始堆轉儲文件的目錄下，一般命名爲“xxx_Leak_Suspects.zip”，xxx是dump文件的名字，如果需要和同事一起分析這個內存問題的話，只需要把這個小小的zip包發給他就可以了，不需要把整個堆文件發給他。並且整個報告是一個HTML格式的文件，用瀏覽器就可以輕鬆打開

內存泄露的概念：
1、內存泄露的這些對象是從GC root可達的，從GC root存在通路可以與其相連
2、這些對象是無用的，即程序以後不會再使用這些對象
至於怎麼定義程序不會再使用的對象，那就要看具體的程序邏輯了，說白了內存泄露就是該回收的內存沒有被回收

下面用一個例子分析如何使用Leak Suspects Report內存泄露報告

public class OOMHeapTest {

public static void main(String[] args){

oom();

}

private static void oom(){

Map<String, OOMBean> map = new HashMap<String, OOMBean>();

Object[] array = new Object[1000000];

for(int i=0; i<1000000; i++){

String d = new Date().toString();

OOMBean o = new OOMBean(d, i);

map.put(i+"_oom", o);

array[i] = o;

}

上面的代碼中創建了很多OOMBean，並放入了Map和數組中，由於是強引用，在主線程運行結束前，GC自然不會回收，一直到內存溢出。

在運行前設置一些VM參數：-Xms2m -Xmx2m -XX:+HeapDumpOnOutOfMemoryError

以便程序可以OutOfMemory，並在發生內存溢出時自動生成內存快照

程序運行一會兒後，控制檯打印

java_pid10160.hprof 就是內存dump，可以在OOMHeapTest類所在工程的根目錄下找到

Leak Suspects：

MAT工具分析了heap dump後在界面上非常直觀的展示了一個餅圖，該圖深色區域被懷疑有內存泄漏，可以發現整個heap才6.8M內存，深色區域就佔了92.11%。接下來是一個簡短的描述，告訴我們main線程佔用了大量內存，並且明確指出system class loader加載的“java.lang.Thread”實例有內存聚集，並建議用關鍵字“java.lang.Thread”進行檢查。在下面還有一個“Details”鏈接，可以查看明細信息。

Details明細：

Details的最開始是Description描述，和前一個頁面對內存泄露嫌疑點的描述一致，下面有一些與懷疑的內存泄露點關聯的查詢結果展示，是分析報告中認爲可能會存在問題，協助我們深入分析問題根源的，具體如下：

（1）Shortest Paths To the Accumulation Point

實際上展開的視圖是當前對象“java.lang.Thread @ 0xffc59ab0 main”的 Path to GC roots，即到GC roots的路徑，點擊標題右側的按鈕可以在另一窗口打開

這個視圖的作用是可以分析是由於和哪個GC root相連導致當前Retained Heap佔用相當大的對象無法被回收

由於是分析內存泄露的報告，找到導致當前對象無法被回收的GC roots，分析這些GC roots是否合理，是有必要的

但本例中由於main線程本身就是GC root，故只有一條數據

（2）Accumulated Objects in Dominator Tree

這個視圖以對象的維度展示了以當前對象“java.lang.Thread @ 0xffc59ab0 main”爲根的 Dominator Tree支配樹，可以方便的看出受當前對象“支配”的對象中哪個佔用Retained Heap比較大

觀察Accumulated Objects部分，java.lang.Object[1000000]實例和 java.util.HashMap 和的Retained Heap(Size)最大，Retained Heap代表從該類實例沿着reference chain往下所能收集到的其他類實例的Shallow Heap(Size)總和，所以明顯類實例都聚集在HashMap和Object數組中了

在Accumulated Objects視圖中，Retained heap佔用最多的是HashMap和object數組，爲啥它們會佔用這麼大的heap呢？這個時候需要分析HashMap和object數組中存放了一些什麼對象？接着往下看 Accumulated Objects by Class in Dominator Tree

（3）Accumulated Objects by Class in Dominator Tree

這個視圖實際上是展示了以當前對象“java.lang.Thread @ 0xffc59ab0 main”爲根的 Dominator Tree支配樹，並以Class類分組

可以看到 OOMBean類的實例最多，有11786個，程序中確實是在循環創建OOMBean實例，並放入object數據和HashMap中

這樣就可以確定Heap佔用大時由於OOMBean類的實例創建的太多的原因了

（4）Thread Detail

Detail明細的最後由於當前懷疑泄露點爲main Thread線程對象，故展示了線程明細信息，調用棧信息，對分析內存溢出的發生位置很有幫忙

參考資料：

Eclipse Memory Analyzer Tool Help

原文鏈接：https://www.cnblogs.com/trust-freedom/p/6744948.html
作者：Trust_FreeDom - 博客園
博客主頁：http://www.cnblogs.com/trust-freedom/
歡迎轉載，但請保留作者和本文鏈接，謝謝！
歡迎在下面的評論區與我交流。

如果覺得寫的不錯，請點擊下面的“推薦”按鈕，讓我更有動力寫出更好的文章。

使用Eclipse Memory Analyzer Tool（MAT）分析線上故障(一) - 視圖&功能篇

視圖 & 功能

1、Overview

2、Histogram視圖

3、Dominator Tree（支配樹）視圖

4、Group分組功能

5、Thread Overview

6、List objects

7、Paths to GC Roots（從對象到GC Roots的路徑） & Merge Shortest Paths to GC roots（從GC Roots到對象的共同路徑）

8、Leak Suspects Report（內存泄露報告）

僞分佈式系列 - 第六篇 - flume-1.9.0-環境搭建

推薦系統系列 - 實例二 - 協同過濾算法-儲備知識

推薦系統系列 - 實例一 - 基於流行度的算法 - 搜索熱詞推薦

Antlr - 使用antlr4實現一個計算器,配合變量可以實現程序裏的複合指標運算

表達式引擎Aviator

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結