Android的內存泄漏怎麼治-----------MAT使用教程

概述

對於大型 JAVA 應用程序來說,再精細的測試也難以堵住所有的漏洞,即便我們在測試階段進行了大量卓有成效的工作,很多問題還是會在生產環境下暴露出來,並且很難在測試環境中進行重現。JVM 能夠記錄下問題發生時系統的部分運行狀態,並將其存儲在堆轉儲 (Heap Dump) 文件中,從而爲我們分析和診斷問題提供了重要的依據。

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

MAT 的使用是如此容易,你是不是也很有興趣來親自感受下呢,那麼第一步我們先來安裝 MAT。

準備環境和測試數據

我們使用的是 Eclipse Memory Analyzer V0.8,Sun JDK 6

安裝 MAT

和其他插件的安裝非常類似,MAT 支持兩種安裝方式,一種是“單機版“的,也就是說用戶不必安裝 Eclipse IDE 環境,MAT 作爲一個獨立的 Eclipse RCP 應用運行;另一種是”集成版“的,也就是說 MAT 也可以作爲 Eclipse IDE 的一部分,和現有的開發平臺集成。

集成版的安裝需要藉助 Update Manager。

如圖 1 所示,首先通過 Help -> Software Updates... 啓動軟件更新管理嚮導。

圖 1. 安裝插件第一步

圖 1. 安裝插件第一步

選擇“Available Software“然後按如圖 2 所示的方式添加 MAT 的更新地址 http://download.eclipse.org/technology/mat/0.8/update-site/

圖 2. 安裝插件第二步

圖 2. 安裝插件第二步

如圖 3 所示,接下來選擇你想要安裝的 MAT 的功能點,需要注意的是 Memory Analyzer (Chart) 這個功能是一個可選的安裝項目,它主要用來生成相關的報表,不過如果需要用到這個功能,你還需要額外的安裝 BIRT Chart Engine。

圖 3. 安裝插件第三步

圖 3. 安裝插件第三步

插件安裝完畢,你還需要重新啓動 Eclipse 的工作平臺。

比較而言,單機版的安裝方式非常簡單,用戶只需要下載相應的安裝包,然後解壓縮即可運行,這也是被普遍採用的一種安裝方式。在下面的例子裏,我們使用的也是單機版的 MAT。具體的下載要求和地址可參見其產品下載頁面:http://www.eclipse.org/mat/downloads.php

另外,如果你需要用 MAT 來分析 IBM JVM 生成的 dump 文件的話,還需要額外安裝 IBM Diagnostic Tool Framework ,具體的下載和安裝配置步驟請參見:http://www.ibm.com/developerworks/java/jdk/tools/dtfj.html

配置環境參數

安裝完成之後,爲了更有效率的使用 MAT,我們還需要做一些配置工作。因爲通常而言,分析一個堆轉儲文件需要消耗很多的堆空間,爲了保證分析的效率和性能,在有條件的情況下,我們會建議分配給 MAT 儘可能多的內存資源。你可以採用如下兩種方式來分配內存更多的內存資源給 MAT。

一種是修改啓動參數 MemoryAnalyzer.exe -vmargs -Xmx4g

另一種是編輯文件 MemoryAnalyzer.ini,在裏面添加類似信息 -vmargs – Xmx4g。

至此,MAT 就已經成功地安裝配置好了,開始進入實戰吧。

獲得堆轉儲文件

巧婦難爲無米之炊,我們首先需要獲得一個堆轉儲文件。爲了方便,本文采用的是 Sun JDK 6。通常來說,只要你設置瞭如下所示的 JVM 參數:

-XX:+HeapDumpOnOutOfMemoryError

JVM 就會在發生內存泄露時抓拍下當時的內存狀態,也就是我們想要的堆轉儲文件。

如果你不想等到發生崩潰性的錯誤時才獲得堆轉儲文件,也可以通過設置如下 JVM 參數來按需獲取堆轉儲文件。

-XX:+HeapDumpOnCtrlBreak

除此之外,還有很多的工具,例如 JMap,JConsole 都可以幫助我們得到一個堆轉儲文件。本文實例就是使用 JMap 直接獲取了 Eclipse Galileo 進程的堆轉儲文件。您可以使用如下命令:

JMap -dump:format=b,file=<dumpfile> <pid>

不過,您需要了解到,不同廠家的 JVM 所生成的堆轉儲文件在數據存儲格式以及數據存儲內容上有很多區別, MAT 不是一個萬能工具,它並不能處理所有類型的堆存儲文件。但是比較主流的廠家和格式,例如 Sun, HP, SAP 所採用的 HPROF 二進制堆存儲文件,以及 IBM 的 PHD 堆存儲文件等都能被很好的解析(您需要安裝額外的插件,請參考 相關說明,本文不作詳細解釋)。

萬事俱備,接下來,我們就可以開始體驗一鍵式的堆存儲分析功能了。

生成分析報告

首先,啓動前面安裝配置好的 Memory Analyzer tool , 然後選擇菜單項 File- Open Heap Dump 來加載需要分析的堆轉儲文件。文件加載完成後,你可以看到如圖 4 所示的界面:

圖 4. 概覽

圖 4. 概覽

通過上面的概覽,我們對內存佔用情況有了一個總體的瞭解。先檢查一下 MAT 生成的一系列文件。

圖 5. 文件列表

圖 5. 文件列表

可以看到 MAT 工具提供了一個很貼心的功能,將報告的內容壓縮打包到一個 zip 文件,並把它存放到原始堆轉儲文件的存放目錄下,這樣如果您需要和同事一起分析這個內存問題的話,只需要把這個小小的 zip 包發給他就可以了,不需要把整個堆文件發給他。並且整個報告是一個 HTML 格式的文件,用瀏覽器就可以輕鬆打開。

接下來我們就可以來看看生成的報告都包括什麼內容,能不能幫我們找到問題所在吧。您可以點擊工具欄上的 Leak Suspects 菜單項來生成內存泄露分析報告,也可以直接點擊餅圖下方的 Reports->Leak Suspects 鏈接來生成報告。

圖 6. 工具欄菜單

圖 6. 工具欄菜單

分析三步曲

通常我們都會採用下面的“三步曲”來分析內存泄露問題:

首先,對問題發生時刻的系統內存狀態獲取一個整體印象。

第二步,找到最有可能導致內存泄露的元兇,通常也就是消耗內存最多的對象

接下來,進一步去查看這個內存消耗大戶的具體情況,看看是否有什麼異常的行爲。

下面將用一個基本的例子來展示如何採用“三步曲”來查看生產的分析報告。

查看報告之一:內存消耗的整體狀況

圖 7. 內存泄露分析報告

圖 7. 內存泄露分析報告

如圖 7 所示,在報告上最醒目的就是一張簡潔明瞭的餅圖,從圖上我們可以清晰地看到一個可疑對象消耗了系統 99% 的內存。

在圖的下方還有對這個可疑對象的進一步描述。我們可以看到內存是由 java.util.Vector 的實例消耗的,com.ibm.oti.vm.BootstrapClassLoader 負責這個對象的加載。這段描述非常短,但我相信您已經可以從中找到很多線索了,比如是哪個類佔用了絕大多數的內存,它屬於哪個組件等等。

接下來,我們應該進一步去分析問題,爲什麼一個 Vector 會佔據了系統 99% 的內存,誰阻止了垃圾回收機制對它的回收。

查看報告之二:分析問題的所在

首先我們簡單回顧下 JAVA 的內存回收機制,內存空間中垃圾回收的工作由垃圾回收器 (Garbage Collector,GC) 完成的,它的核心思想是:對虛擬機可用內存空間,即堆空間中的對象進行識別,如果對象正在被引用,那麼稱其爲存活對象,反之,如果對象不再被引用,則爲垃圾對象,可以回收其佔據的空間,用於再分配。

在垃圾回收機制中有一組元素被稱爲根元素集合,它們是一組被虛擬機直接引用的對象,比如,正在運行的線程對象,系統調用棧裏面的對象以及被 system class loader 所加載的那些對象。堆空間中的每個對象都是由一個根元素爲起點被層層調用的。因此,一個對象還被某一個存活的根元素所引用,就會被認爲是存活對象,不能被回收,進行內存釋放。因此,我們可以通過分析一個對象到根元素的引用路徑來分析爲什麼該對象不能被順利回收。如果說一個對象已經不被任何程序邏輯所需要但是還存在被根元素引用的情況,我們可以說這裏存在內存泄露。

現在,讓我們開始真正的尋找內存泄露之旅,點擊“Details ”鏈接,可以看到如圖 8 所示對可疑對象 1 的詳細分析報告。

圖 8. 可疑對象 1 的詳細分析報告

圖 8. 可疑對象 1 的詳細分析報告

  1. 我們查看下從 GC 根元素到內存消耗聚集點的最短路徑:

圖 9. 從根元素到內存消耗聚集點的最短路徑

圖 9. 從根元素到內存消耗聚集點的最短路徑

我們可以很清楚的看到整個引用鏈,內存聚集點是一個擁有大量對象的集合,如果你對代碼比較熟悉的話,相信這些信息應該能給你提供一些找到內存泄露的思路了。

接下來,我們再繼續看看,這個對象集合裏到底存放了什麼,爲什麼會消耗掉如此多的內存。

圖 10. 內存消耗聚集對象信息

圖 10. 內存消耗聚集對象信息

在這張圖上,我們可以清楚的看到,這個對象集合中保存了大量 Person 對象的引用,就是它導致的內存泄露。

至此,我們已經擁有了足夠的信息去尋找泄露點,回到代碼,我們發現,是下面的代碼導致了內存泄露 :

清單 1. 內存泄漏的代碼段

1

2

3

4

5

6

7

while (1<2)

{

            

    Person person = new Person("name","address",i);

    v.add(person);

    person = null;

}

總結

從上面的例子我們可以看到用 MAT 來進行堆轉儲文件分析,尋找內存泄露非常簡單,尤其是對於新手而言,這是一個很好的輔助分析工具。但是,MAT 絕對不僅僅是一個“傻瓜式”內存分析工具,它還提供很多高級功能,比如 MAT 支持用 OQL(Object Query Language)對 heap dump 中的對象進行查詢,支持對線程的分析等,有關這些功能的使用可以參考 MAT 的幫助文檔。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章