在實際開發中或多或少我們都會遇到java的記憶體問題，特別是開發android程式和大型 JAVA 應用程式來說，再精細的測試也難以堵住所有的漏洞，即便我們在測試階段進行了大量卓有成效的工作，很多問題還是會在生產環境下暴露出來，並且很難在測試環境中進行重現。JVM 能夠記錄下問題發生時系統的部分執行狀態，並將其儲存在堆轉儲 (Heap Dump) 檔案中，從而為我們分析和診斷問題提供了重要的依據。

通常記憶體洩露分析被認為是一件很有難度的工作，一般由團隊中的資深人士進行。不過，今天我們要介紹的 MAT（Eclipse Memory Analyzer）被認為是一個“傻瓜式“的堆轉儲檔案分析工具，你只需要輕輕點選一下滑鼠就可以生成一個專業的分析報告。和其他記憶體洩露分析工具相比，MAT 的使用非常容易，基本可以實現一鍵到位，即使是新手也能夠很快上手使用。

上一篇檔案我們已經順利在myeclipse上安裝了mat外掛並生成了.hprof檔案。這裡我們將主要看看這個分析報告怎麼看，本人也是第一次使用，如果有什麼不對的地方還請不吝指正

重啟後提示安裝成功

再次雙擊開啟.hprof檔案可以看到

通過上面的概覽，我們對記憶體佔用情況有了一個總體的瞭解。先檢查一下 MAT 生成的一系列檔案。

接下來我們就可以來看看生成的報告都包括什麼內容，能不能幫我們找到問題所在吧。您可以點選工具欄上的 Leak Suspects 選單項來生成記憶體洩露分析報告，也可以直接點選餅圖下方的 Reports->Leak Suspects 連結來生成報告。

下面開始分析報告，一般三個步驟：

1.檢視整體的記憶體狀況，先看Leak Suspects（可疑洩漏點圖）

從圖中可以看到有個佔了52兆記憶體的物件，物件是一個map。為什麼會一個map佔據了系統52m的記憶體，誰阻止了垃圾回收機制對它的回收，接下來點選

2.分析原因找到問題所在，首先我們簡單回顧下 JAVA 的記憶體回收機制，記憶體空間中垃圾回收的工作由垃圾回收器 (Garbage Collector,GC) 完成的，它的核心思想是：對虛擬機器可用記憶體空間，即堆空間中的物件進行識別，如果物件正在被引用，那麼稱其為存活物件，反之，如果物件不再被引用，則為垃圾物件，可以回收其佔據的空間，用於再分配。
在垃圾回收機制中有一組元素被稱為根元素集合，它們是一組被虛擬機器直接引用的物件，比如，正在執行的執行緒物件，系統呼叫棧裡面的物件以及被 system class loader 所載入的那些物件。堆空間中的每個物件都是由一個根元素為起點被層層呼叫的。因此，一個物件還被某一個存活的根元素所引用，就會被認為是存活物件，不能被回收，進行記憶體釋放。因此，我們可以通過分析一個物件到根元素的引用路徑來分析為什麼該物件不能被順利回收。如果說一個物件已經不被任何程式邏輯所需要但是還存在被根元素引用的情況，我們可以說這裡存在記憶體洩露。
現在，讓我們開始真正的尋找記憶體洩露之旅，點選“Details ”連結，可以看到如下圖圖所示對可疑物件 1 的詳細分析報告。

可以看到程式有大量的map元素沒有被釋放。這個資訊足夠我們去原始碼裡面需找原因了。 3.檢視原始碼分析錯誤，這個例子的錯誤很明顯，不分析了