如何理解Dominator Tree

本篇內容主要講解“如何理解Dominator Tree”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何理解Dominator Tree”吧!

視圖 & 功能

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視圖”鏈接

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分析，看到線程棧幀中的本地變量，在左下方的對象屬性區域還能看到本地變量的屬性，真的很方便

在上面代碼的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行中的

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 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格式的文件，用瀏覽器就可以輕松打開

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

上面的代碼中創建了很多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線程對象，故展示了線程明細信息，調用棧信息，對分析內存溢出的發生位置很有幫忙

到此，相信大家對“如何理解Dominator Tree”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！