??? 內存泄漏是比較常見的一種應用程序性能問題，一旦發生，則系統的可用內存和性能持續下降；最終將導致內存不足(OutOfMemory)，系統徹底宕掉，不能響應任何請求，其危害相當嚴重。同時，Java堆(Heap)中大量的對象以及對象間之復雜關系，導致內存泄漏問題的探測和分析均比較困難，采用相應的輔助工具是很必要的。

我使用的比較多的是Memory Dump Diagnostic for Java (MDD4J)和IBM HeapAnalyzer，這兩個工具都能支持幾乎所有JDK版本所生成的堆轉儲文件，使用前可以在兩者的幫助文件中查看一下支持列表。

先說一下IBM HeapAnalyzer，下載之后首先閱讀一下readme，這上面詳細寫了HeapAnalyzer的使用方法。對于我用的2.6版本（最新為3.8），可以在命令行中輸入<Java path>java –Xmx[heapsize] –jar ha26.jar <heapdump file>來啟動工具并加載heapdump文件。對于比較大的heapdump，將-Xmx設置一個較大的值（大于heapdump的大小），來避免加載過程中的OOM。對于64位機器上產生的超大heapdump，個人機器上分析就不大可能了。

打開heapdump文件后，我一般點擊“Analysis”里的“Tree View”，以樹的形式從根節點展示內存對象分配的信息

heapanalysis1

第一行java.lang.ref.Refenrence這個class及它的76個children占用了67%的已用堆大小（31M/46M），它本身僅占用了76bits。雙擊java.lang.ref.Refenrence，我們可以看到它所引用的兩個子節點。其中一個子節點java.lang.ref.Finalizer后的67%指引我們內存泄漏的問題應該在它的引用上。

heapanalysis2

接下去你可以逐級展開，或者右鍵點擊“Locate a leak suspect”，讓HeapAnalyzer幫你找到泄漏可能發生的地方。泄漏一般發生在那些擁有“超乎尋常多”的引用（子節點）的class上，正是這些創建后沒有釋放、累積了成千上百的對象，造成了OutOfMemory。右鍵中的“Go to the largest drop subtrees”也是以此為原理而設的，它的解釋為：

??? “Search for total size drop” will find a size drop between the total size of a parent and the biggest total size of child of the parent.

因為出現泄漏的點，每個子節點占用的內存空間不大，但是巨大的數量會導致父節點占用的total size很大。不過反過來尋找到的點都是泄漏發生的地方這種說法是不成立的，否則也不需要我們來分析了。

更多細節的內容，可以看這篇PPT

Memory Dump Diagnostic for Java (MDD4J)則是IBM Support Assistant（ISA）里的一個工具，可以在ISA里加載。它的使用方法和HeapAnalyzer類似，不過它會自動列出“可疑泄漏點”供分析。所依據的，是“分析算法查找父對象與子對象之間對象大小的顯著變化。這些發生顯著變化的父對象可能是基于數組的容器對象，它們包含大量不斷增大的子對象。”

具體的使用方法可以參考《WebSphere Application Server 中的內存泄漏檢測與分析:第 2 部分：用于泄漏檢測與分析的工具和功能》一文中的實際案例。（不過文中的版本應該比較低，現在能下到的2和3版本有些不同，不過不妨礙使用）.

Heapdump工具的使用很簡單，難點在于找到“內存泄漏的真正原因”，一般需要通過多個heapdump文件的對比才能找到。

??? 比較分析用于對運行內存泄漏應用程序期間（即可用 Java 堆內存流失時）獲取的兩個內存轉儲進行分析。在運行泄漏應用程序的早期觸發的內存轉儲被稱為基線內存轉儲，發生泄漏的應用程序運行一段時間（以允許泄漏程度加大）后觸發的內存轉儲被稱為主內存轉儲。在發生了內存泄漏的情況下，主內存轉儲可能包含大量對象，而這些對象占用的 Java 堆空間量會比基線內存轉儲大很多。

??? 為了獲得更好的分析結果，建議使主內存轉儲的觸發點與基線內存轉儲的觸發點在時間上拉開一定距離，從而使總耗用堆大小在兩個觸發點之間大幅增長。

如果發現“主內存轉儲”中的某個對象數量大大大于“基線內存轉儲”，那么這個對象一般就是發生泄漏的點。但是要避免在appserver剛啟動時就做heapdump，否則會把正常需要分配的對象當作泄漏嫌疑點。比如原先運行3天會發生OOM，那么可以：縮小堆大小，讓OOM提早發生；在運行4個小時后每隔4小時手動做一次Heapdump直到OOM發生。這些動作也許不適合在生產環境下進行，可以另建測試環境進行。

之前幾篇文章中介紹的分析gc log，和本文講到的分析heapdump，都是脫機分析法。它們的缺陷就是無法找到代碼引起的“性能低下”的原因，正如《用HPjtune分析GC日志》里所看到的那樣，系統性能很差，但是沒有OOM發生，可用堆在每次full gc后還不斷減少的現象不能簡單怪罪為內存泄漏，畢竟最后都回收下來了，如果手動做heapdump，可能有問題的對象已被回收，無法得到正確的結果。這種情況下要使用諸如Jprofile這樣直接附加到JVM上的工具來監測了。

最后附一下手動生成heapdump的方法，免得事到臨頭在google。

在Linux/AIX環境下

使用Kill -3 pid命令來調用堆轉儲.

Windows環境下

??? 1． 找到JVM對象名字。

??? <wsadmin> set objectName [$AdminControl queryNames
??? WebSphere:type=JVM,process=<servername>,node=<nodename>,*]


??? 2． 對JVM MBean調用generateHeapDump操作。

??? <wsadmin> $AdminControl invoke $objectName generateHeapDump

如果上述方法是沒有生成，那么進行下面的設置。

??? 訪問管理控制臺
??? 轉到“服務器”>“應用程序服務器”> Server1（或者要獲取其堆轉儲的服務器的名稱）>“進程定義”>“環境條目”。
??? 單擊“新建”。
??? 在“名稱”字段中，輸入 IBM_HEAPDUMP（默認是開啟的）。在“值”字段中，輸入 true。
??? 單擊“確定”。
??? 重復步驟 3 至 5，但將 IBM_HEAPDUMP_OUTOFMEMORY 設置為 true。
??? 缺省情況下，將在 ~/WebSphere/AppServer/ 目錄中創建內存轉儲（對于 WebSphere Application Server V6.x 而言，缺省目錄是：~/WebSphere/AppServer/profiles/default）。要將堆轉儲目標定向到另一個目錄，請轉至“環境條目”，單擊“新建”，將 IBM_HEAPDUMPDIR 設置為適當的目錄（例如 /heapdumps），然后單擊“確定”。
??? 單擊“保存”，然后在下一個屏幕中再次單擊“保存”。
??? 轉到“服務器”>“應用程序服務器”> server1（或者要獲取其堆轉儲的服務器的名稱）>“進程定義”>“Java 虛擬機”。
??? 選擇“詳細垃圾回收”。
??? 單擊“保存”，然后在下一個屏幕中再次單擊“保存”。
??? 重新啟動服務器。
??? 打開命令提示符并轉至 /WebSphere/AppServer/bin 目錄。
??? 通過發出 kill -3 XXXXX 命令來調用堆轉儲，其中 XXXXX 是進程標識。

如果WebSphere運行在HP-UX上，那么需要

??? 訪問管理控制臺
??? 轉到“服務器”>“應用程序服務器”> Server1（或者要獲取其堆轉儲的服務器的名稱）>“進程定義”>“環境條目”。
??? 在“常規參數”中，輸入：-Xrunhprof:depth=0,heap=dump,format=a,thread=n,doe=n
??? 缺省情況下，將在 ~/Websphere/AppServer/ 目錄中創建內存轉儲。要將堆轉儲目標定向到另一個目錄，請添加 HProf 參數 file=/heapdumpdir/hprof.txt，其中 heapdumpdir 是適當的目錄，而 hprof.txt 是適當的文件名。如果創建了多個內存轉儲，那么將把每個內存轉儲追加到同一個 hprof.txt 文件中。
??? 選中“啟用詳細垃圾回收方式”。
??? 重新啟動服務器。
??? 通過發出 kill -3 XXXXX 命令創建堆轉儲，其中 XXXXX 是進程標識。
??? 除非另有指定，否則將在 ~/WebSphere/AppServer/ 目錄中創建 hprof 轉儲，并且文件名看起來類似于 java.hprof.txt。
??? 關閉應用程序服務器，然后移動 hprof 轉儲文件。直到正確關閉應用程序服務器之后，hprof 轉儲文件才完整。
??? 注意：請檢查是否每個 hprof 轉儲都包含 HEAP DUMP BEGIN 和 HEAP DUMP END 這兩組標記。如果 hprof 轉儲的這兩組標記不齊全，那么表明該轉儲不完整且不能用于分析。

?

?

轉載?? http://www.hashei.me/2009/07/heapanalyzer-and-mod4j-introduction.html

用IBM HeapAnalyzer和MOD4J分析Java內存泄漏