對於大型 JAVA 應用程序來講,再精細的測試也難以堵住全部的漏洞,即使咱們在測試階段進行了大量卓有成效的工做,不少問題仍是會在生產環境下暴露出來,而且很難在測試環境中進行重現。JVM 可以記錄下問題發生時系統的部分運行狀態,並將其存儲在堆轉儲 (Heap Dump) 文件中,從而爲咱們分析和診斷問題提供了重要的依據。php
一般內存泄露分析被認爲是一件頗有難度的工做,通常由團隊中的資深人士進行。不過,今天咱們要介紹的 MAT(Eclipse Memory Analyzer)被認爲是一個「傻瓜式「的堆轉儲文件分析工具,你只須要輕輕點擊一下鼠標就能夠生成一個專業的分析報告。和其餘內存泄露分析工具相比,MAT 的使用很是容易,基本能夠實現一鍵到位,即便是新手也可以很快上手使用。html
MAT 的使用是如此容易,你是否是也頗有興趣來親自感覺下呢,那麼第一步咱們先來安裝 MAT。java
回頁首瀏覽器
咱們使用的是 Eclipse Memory Analyzer V0.8,Sun JDK 6eclipse
和其餘插件的安裝很是相似,MAT 支持兩種安裝方式,一種是「單機版「的,也就是說用戶沒必要安裝 Eclipse IDE 環境,MAT 做爲一個獨立的 Eclipse RCP 應用運行;另外一種是」集成版「的,也就是說 MAT 也能夠做爲 Eclipse IDE 的一部分,和現有的開發平臺集成。工具
集成版的安裝須要藉助 Update Manager。性能
如圖 1 所示,首先經過 Help -> Software Updates... 啓動軟件更新管理嚮導。測試
選擇「Available Software「而後按如圖 2 所示的方式添加 MAT 的更新地址 http://download.eclipse.org/mat/1.4/update-site/插件
開源訪問: http://www.eclipse.org/mat/downloads.php線程
如圖 3 所示,接下來選擇你想要安裝的 MAT 的功能點,須要注意的是 Memory Analyzer (Chart) 這個功能是一個可選的安裝項目,它主要用來生成相關的報表,不過若是須要用到這個功能,你還須要額外的安裝 BIRT Chart Engine。
插件安裝完畢,你還須要從新啓動 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 所示的界面:
經過上面的概覽,咱們對內存佔用狀況有了一個整體的瞭解。先檢查一下 MAT 生成的一系列文件。
能夠看到 MAT 工具提供了一個很貼心的功能,將報告的內容壓縮打包到一個 zip 文件,並把它存放到原始堆轉儲文件的存放目錄下,這樣若是您須要和同事一塊兒分析這個內存問題的話,只須要把這個小小的 zip 包發給他就能夠了,不須要把整個堆文件發給他。而且整個報告是一個 HTML 格式的文件,用瀏覽器就能夠輕鬆打開。
接下來咱們就能夠來看看生成的報告都包括什麼內容,能不能幫咱們找到問題所在吧。您能夠點擊工具欄上的 Leak Suspects 菜單項來生成內存泄露分析報告,也能夠直接點擊餅圖下方的 Reports->Leak Suspects 連接來生成報告。
一般咱們都會採用下面的「三步曲」來分析內存泄露問題:
首先,對問題發生時刻的系統內存狀態獲取一個總體印象。
第二步,找到最有可能致使內存泄露的元兇,一般也就是消耗內存最多的對象
接下來,進一步去查看這個內存消耗大戶的具體狀況,看看是否有什麼異常的行爲。
下面將用一個基本的例子來展現如何採用「三步曲」來查看生產的分析報告。
如圖 7 所示,在報告上最醒目的就是一張簡潔明瞭的餅圖,從圖上咱們能夠清晰地看到一個可疑對象消耗了系統 99% 的內存。
在圖的下方還有對這個可疑對象的進一步描述。咱們能夠看到內存是由 java.util.Vector 的實例消耗的,com.ibm.oti.vm.BootstrapClassLoader 負責這個對象的加載。這段描述很是短,但我相信您已經能夠從中找到不少線索了,好比是哪一個類佔用了絕大多數的內存,它屬於哪一個組件等等。
接下來,咱們應該進一步去分析問題,爲何一個 Vector 會佔據了系統 99% 的內存,誰阻止了垃圾回收機制對它的回收。
首先咱們簡單回顧下 JAVA 的內存回收機制,內存空間中垃圾回收的工做由垃圾回收器 (Garbage Collector,GC) 完成的,它的核心思想是:對虛擬機可用內存空間,即堆空間中的對象進行識別,若是對象正在被引用,那麼稱其爲存活對象,反之,若是對象再也不被引用,則爲垃圾對象,能夠回收其佔據的空間,用於再分配。
在垃圾回收機制中有一組元素被稱爲根元素集合,它們是一組被虛擬機直接引用的對象,好比,正在運行的線程對象,系統調用棧裏面的對象以及被 system class loader 所加載的那些對象。堆空間中的每一個對象都是由一個根元素爲起點被層層調用的。所以,一個對象還被某一個存活的根元素所引用,就會被認爲是存活對象,不能被回收,進行內存釋放。所以,咱們能夠經過分析一個對象到根元素的引用路徑來分析爲何該對象不能被順利回收。若是說一個對象已經不被任何程序邏輯所須要可是還存在被根元素引用的狀況,咱們能夠說這裏存在內存泄露。
如今,讓咱們開始真正的尋找內存泄露之旅,點擊「Details 」連接,能夠看到如圖 8 所示對可疑對象 1 的詳細分析報告。
咱們能夠很清楚的看到整個引用鏈,內存匯集點是一個擁有大量對象的集合,若是你對代碼比較熟悉的話,相信這些信息應該能給你提供一些找到內存泄露的思路了。
接下來,咱們再繼續看看,這個對象集合裏到底存放了什麼,爲何會消耗掉如此多的內存。
在這張圖上,咱們能夠清楚的看到,這個對象集合中保存了大量 Person 對象的引用,就是它致使的內存泄露。
至此,咱們已經擁有了足夠的信息去尋找泄露點,回到代碼,咱們發現,是下面的代碼致使了內存泄露 :
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 的幫助文檔。
reference: http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-ma/index.html