JAVA內存泄露檢測工具(IBM HeapAnalyzer)

HeapAnalyzer 是 IBM 的一個用來分析 Java 程序的內存堆使用情況的圖形化工具。

IBM HeapAnalyzer怎么用？

IBM HeapAnalyzer，下載之后首先閱讀一下readme，這上面詳細寫了HeapAnalyzer的使用方法�？梢栽诿�令行中輸入java –Xmx[heapsize] –jar ha26.jar 來啟動工具并加載heapdump文件。對于比較大的heapdump，將-Xmx設置一個較大的值（大于heapdump的大�。�，來避免加載過程中的OOM。對于64位機器上產生的超大heapdump，個人機器上分析就不大可能了。

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

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

接下去你可以逐級展開，或者右鍵點擊“Locate a leak suspect”，讓HeapAnalyzer幫你找到泄漏可能發(fā)生的地方。泄漏一般發(fā)生在那些擁有“超乎尋常多”的引用（子節(jié)點）的class上，正是這些創(chuàng)建后沒有釋放、累積了成千上百的對象，造成了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.

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

如何分析 java heap dump 文件？

如果啟動過程中發(fā)現(xiàn)控制臺有java.lang.OutOfMemoryError出現(xiàn)，可以適當加大上面的數(shù)字（800），給予更多的空間。

然后“Open”產生的dump文件，打開畫面如下，文件很大的話需要等待一段時間

ibm heapAnalyzer工具在打開時已經進行了基本的分析，上面全部完成后，會出現(xiàn)如下結果：

[-photo didnot display-]

除了顯示該要結果外，還生成了一棵樹。這個畫面先不要關，直到你不再需要這個dump了。

基本術語：

[-photo didnot display-]

然后對上面的界面做一下簡單的介紹。

[-photo didnot display-]

每個節(jié)點樹的大小占總的堆棧大小，如94%，然后是這個類的在內存中的大小，后面5個子對象，注意這個子對象的意思不是繼承關系中的子類，而是上面定義的：如果A對象參考B對象，則B對象是A對象的字對象。

然后該工具根據(jù)分析結果把可能產生泄漏的對象顯示了出來。如下圖：

[-photo didnot display-]

分析根據(jù)主要是child object和parent object的大小差別程度，如果子對象不大，而父對象超級大，很可能是因為父對象是一個集合類（如數(shù)組），包含了大量子對象作為元素。

工具欄：

[-photo didnot display-]

點擊分析工具欄的表格圖標，顯示出下面的統(tǒng)計表格，可以點擊欄標題進行排序。各標題意思簡單介紹如下：

TotalSize：這個對象，以及這個對象的所有子對象（以及子對象的子對象，也就是從這個對象可以參考到的所有對象）的大小的總和，單位為bits；

Size:這個對象的大小，如第一個56bits = 56/8bytes = 7b；

No.Child：子對象的個數(shù)，不包括子對象的子對象；

No.Parent：父對象的個數(shù)，不包括父對象的對象；

Name：對象的名稱。

Address：對象在heap中的地址。

1.分析結果

1.1大量的以java/util/HashMap$Entry為元素的數(shù)組，占據(jù)了總堆棧的8%，很高的比例。

1.2大量的java/util/Hashtable$HashtableEntry為元素的數(shù)組，占據(jù)總堆棧的5%。

1.3里面的數(shù)組大量指向java/util/Hashtable$HashtableCacheHashEntry對象。

根據(jù)分析，最有嫌疑的對象應該是java/util/HashMap$Entry。

2.其他經驗收集：

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

“ObjectInputStream/ObjectOutputStream要注意內存泄漏.reset()”

“因為JDK的問題，如果使用的是：J2RE 5.0 IBM J9 2.3AIX ppc-32 build j9vmap3223-20070201，這個SR4的版本有個問題就是，限定了類加載器可加載的類數(shù)量，默認為8192，如果超過此限制，就會拋出　OutOfMemory的錯誤。”

對于這個問題，可以設置增加類加載器可加載的類數(shù)量解決。

3.知識補充介紹

3.1堆(Heap)和非堆(Non-heap)內存
按照官方的說法：“Java虛擬機具有一個堆，堆是運行時數(shù)據(jù)區(qū)域，所有類實例和數(shù)組的內存均從此處分配。堆是在Java虛擬機啟動時創(chuàng)建的�！薄霸贘VM中堆之外的內存稱為非堆內存(Non-heap memory)”�？梢钥闯鯦VM主要管理兩種類型的內存：堆和非堆。簡單來說堆就是Java代碼可及的內存，是留給開發(fā)人員使用的；非堆就是JVM留給自己用的，所以方法區(qū)、JVM內部處理或優(yōu)化所需的內存(如JIT編譯后的代碼緩存)、每個類結構(如運行時常數(shù)池、字段和方法數(shù)據(jù))以及方法和構造方法的代碼都在非堆內存中。

3.2堆內存分配
JVM初始分配的內存由-Xms指定，默認是物理內存的1/64；JVM最大分配的內存由-Xmx指定，默認是物理內存的1/4。默認空余堆內存小于40%時，JVM就會增大堆直到-Xmx的最大限制；空余堆內存大于70%時，JVM會減少堆直到-Xms的最小限制。因此服務器一般設置-Xms、-Xmx相等以避免在每次GC后調整堆的大小。

33非堆內存分配
JVM使用-XX：PermSize設置非堆內存初始值，默認是物理內存的1/64；由XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的1/4。

3.4JVM內存限制(最大值)
首先JVM內存限制于實際的最大物理內存，假設物理內存無限大的話，JVM內存的最大值跟操作系統(tǒng)有很大的關系。簡單的說就32位處理器雖然可控內存空間有4GB,但是具體的操作系統(tǒng)會給一個限制，這個限制一般是2GB-3GB（一般來說Windows系統(tǒng)下為1.5G -2G，Linux系統(tǒng)下為2G -3G），而64bit以上的處理器就不會有限制了。