內存分析

使用Memory Analyzer tool(MAT)分析內存泄漏（二）

前言的前言

寫blog就是好，在大前提下可以想說什麼寫什麼，不像投稿那麼字字斟酌。上週末回了趟成都辦事，所以本文來遲了。K117從達州經由達成線往成都方向走的時候，發現鐵路邊有條河，儘管我現在也不知道其名字，但已被其深深的陶醉。河很寬且水流平緩，河邊山丘森林密佈，民房星星點點的分佈在河邊，河裏偶爾些小船。當時我就在想，在這裏生活是多麼的愜意，夏天還可以下去暢遊一番，閒來無事也可垂釣。唉，越來越討厭北漂了。

前言

在使用Memory Analyzer tool(MAT)分析內存泄漏（一）中，我介紹了內存泄漏的前因後果。在本文中，將介紹MAT如何根據heap dump分析泄漏根源。由於測試範例可能過於簡單，很容易找出問題，但我期待藉此舉一反三。
一開始不得不說說ClassLoader，本質上，它的工作就是把磁盤上的類文件讀入內存，然後調用java.lang.ClassLoader.defineClass方法告訴系統把內存鏡像處理成合法的字節碼。Java提供了抽象類ClassLoader，所有用戶自定義類裝載器都實例化自ClassLoader的子類。system class loader在沒有指定裝載器的情況下默認裝載用戶類，在Sun Java 1.5中既sun.misc.Launcher$AppClassLoader。更詳細的內容請參看下面的資料。


準備heap dump

請看下面的Pilot類，沒啥特殊的。

/**
 * Pilot class
 * @author rosen jiang
 */
package org.rosenjiang.bo;

public class Pilot{
    
    String name;
    int age;
    
    public Pilot(String a, int b){
        name = a;
        age = b;
    }
}

然後再看OOMHeapTest類，它是如何撐破heap dump的。

/**
 * OOMHeapTest class
 * @author rosen jiang
 */
package org.rosenjiang.test;

import java.util.Date;
import java.util.HashMap;
import java.util.Map;
import org.rosenjiang.bo.Pilot;

public class OOMHeapTest {
    public static void main(String[] args){
        oom();
    }
    
    private static void oom(){
        Map<String, Pilot> map = new HashMap<String, Pilot>();
        Object[] array = new Object[1000000];
        for(int i=0; i<1000000; i++){
            String d = new Date().toString();
            Pilot p = new Pilot(d, i);
            map.put(i+"rosen jiang", p);
            array[i]=p;
        }
    }
}

是的，上面構造了很多的Pilot類實例，向數組和map中放。由於是Strong Ref，GC自然不會回收這些對象，一直放在heap中直到溢出。當然在運行前，先要在Eclipse中配置VM參數-XX:+HeapDumpOnOutOfMemoryError。好了，一會兒功夫內存溢出，控制檯打出如下信息。

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid3600.hprof 
Heap dump file created [78233961 bytes in 1.995 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

java_pid3600.hprof既是heap dump，可以在OOMHeapTest類所在的工程根目錄下找到。

MAT安裝

話分兩頭說，有了heap dump還得安裝MAT。可以在http://www.eclipse.org/mat/downloads.php選擇合適的方式安裝。安裝完成後切換到Memory Analyzer視圖。在Eclipse的左上角有Open Heap Dump按鈕，按照剛纔說的路徑找到java_pid3600.hprof文件並打開。解析hprof文件會花些時間，然後會彈出嚮導，直接Finish即可。稍後會看到下圖所示的界面。



MAT工具分析了heap dump後在界面上非常直觀的展示了一個餅圖，該圖深色區域被懷疑有內存泄漏，可以發現整個heap才64M內存，深色區域就佔了99.5%。接下來是一個簡短的描述，告訴我們main線程佔用了大量內存，並且明確指出system class loader加載的"java.lang.Thread"實例有內存聚集，並建議用關鍵字"java.lang.Thread"進行檢查。所以，MAT通過簡單的兩句話就說明了問題所在，就算使用者沒什麼處理內存問題的經驗。在下面還有一個"Details"鏈接，在點開之前不妨考慮一個問題：爲何對象實例會聚集在內存中，爲何存活（而未被GC）？是的——Strong Ref，那麼再走近一些吧。



點擊了"Details"鏈接之後，除了在上一頁看到的描述外，還有Shortest Paths To the Accumulation Point和Accumulated Objects部分，這裏說明了從GC root到聚集點的最短路徑，以及完整的reference chain。觀察Accumulated Objects部分，java.util.HashMap和java.lang.Object[1000000]實例的retained heap(size)最大，在上一篇文章中我們知道retained heap代表從該類實例沿着reference chain往下所能收集到的其他類實例的shallow heap(size)總和，所以明顯類實例都聚集在HashMap和Object數組中了。這裏我們發現一個有趣的現象，既Object數組的shallow heap和retained heap竟然一樣，通過Shallow and retained sizes一文可知，數組的shallow heap和一般對象（非數組）不同，依賴於數組的長度和裏面的元素的類型，對數組求shallow heap，也就是求數組集合內所有對象的shallow heap之和。好，再來看org.rosenjiang.bo.Pilot對象實例的shallow heap爲何是16，因爲對象頭是8字節，成員變量int是4字節、String引用是4字節，故總共16字節。



接着往下看，來到了Accumulated Objects by Class區域，顧名思義，這裏能找到被聚集的對象實例的類名。org.rosenjiang.bo.Pilot類上頭條了，被實例化了290,325次，再返回去看程序，我承認是故意這麼幹的。還有很多有用的報告可用來協助分析問題，只是本文中的例子太簡單，也用不上。以後如有用到，一定撰文詳細敘述。

又是perm gen

我們在上一篇文章中知道，perm gen是個異類，裏面存儲了類和方法數據（與class loader有關）以及interned strings（字符串駐留）。在heap dump中沒有包含太多的perm gen信息。那麼我們就用這些少量的信息來解決問題吧。

看下面的代碼，利用interned strings把perm gen撐破了。

/**
 * OOMPermTest class
 * @author rosen jiang
 */
package org.rosenjiang.test;

public class OOMPermTest {
    public static void main(String[] args){
        oom();
    }
    
    private static void oom(){
        Object[] array = new Object[10000000];
        for(int i=0; i<10000000; i++){
            String d = String.valueOf(i).intern();
            array[i]=d;
        }
    }
}

控制檯打印如下的信息，然後把java_pid1824.hprof文件導入到MAT。其實在MAT裏，看到的狀況應該和“OutOfMemoryError: Java heap space”差不多（用了數組），因爲heap dump並沒有包含interned strings方面的任何信息。只是在這裏需要強調，使用intern()方法的時候應該多加註意。

java.lang.OutOfMemoryError: PermGen space
Dumping heap to java_pid1824.hprof 
Heap dump file created [121273334 bytes in 2.845 secs]
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space

倒是在思考如何把class loader撐破廢了些心思。經過嘗試，發現使用ASM來動態生成類才能達到目的。ASM(http://asm.objectweb.org)的主要作用是處理已編譯類(compiled class)，能對已編譯類進行生成、轉換、分析（功能之一是實現動態代理），而且它運行起來足夠的快和小巧，文檔也全面，實屬居家必備之良品。ASM提供了core API和tree API，前者是基於事件的方式，後者是基於對象的方式，類似於XML的SAX、DOM解析，但是使用tree API性能會有損失。既然下面要用到ASM，這裏不得不囉嗦下已編譯類的結構，包括：
    1、修飾符（例如public、private）、類名、父類名、接口和annotation部分。
    2、類成員變量聲明，包括每個成員的修飾符、名字、類型和annotation。
    3、方法和構造函數描述，包括修飾符、名字、返回和傳入參數類型，以及annotation。當然還包括這些方法或構造函數的具體Java字節碼。
    4、常量池(constant pool)部分，constant pool是一個包含類中出現的數字、字符串、類型常量的數組。



已編譯類和原來的類源碼區別在於，已編譯類只包含類本身，內部類不會在已編譯類中出現，而是生成另外一個已編譯類文件；其二，已編譯類中沒有註釋；其三，已編譯類沒有package和import部分。
這裏還得說說已編譯類對Java類型的描述，對於原始類型由單個大寫字母表示，Z代表boolean、C代表char、B代表byte、S代表short、I代表int、F代表float、J代表long、D代表double；而對類類型的描述使用內部名(internal name)外加前綴L和後面的分號共同表示來表示，所謂內部名就是帶全包路徑的表示法，例如String的內部名是java/lang/String；對於數組類型，使用單方括號加上數據元素類型的方式描述。最後對於方法的描述，用圓括號來表示，如果返回是void用V表示，具體參考下圖。



下面的代碼中會使用ASM core API，注意接口ClassVisitor是核心，FieldVisitor、MethodVisitor都是輔助接口。ClassVisitor應該按照這樣的方式來調用：visit visitSource? visitOuterClass? ( visitAnnotation | visitAttribute )*( visitInnerClass | visitField | visitMethod )* visitEnd。就是說visit方法必須首先調用，再調用最多一次的visitSource，再調用最多一次的visitOuterClass方法，接下來再多次調用visitAnnotation和visitAttribute方法，最後是多次調用visitInnerClass、visitField和visitMethod方法。調用完後再調用visitEnd方法作爲結尾。

注意ClassWriter類，該類實現了ClassVisitor接口，通過toByteArray方法可以把已編譯類直接構建成二進制形式。由於我們要動態生成子類，所以這裏只對ClassWriter感興趣。首先是抽象類原型：

/**
 * @author rosen jiang
 * MyAbsClass class
 */
package org.rosenjiang.test;

public abstract class MyAbsClass {
    int LESS = -1;
    int EQUAL = 0;
    int GREATER = 1;
    abstract int absTo(Object o);
}

其次是自定義類加載器，實在沒法，ClassLoader的defineClass方法都是protected的，要加載字節數組形式（因爲toByteArray了）的類只有繼承一下自己再實現。

/**
 * @author rosen jiang
 * MyClassLoader class
 */
package org.rosenjiang.test;

public class MyClassLoader extends ClassLoader {
    public Class defineClass(String name, byte[] b) {
        return defineClass(name, b, 0, b.length);
    }
}

最後是測試類。

/**
 * @author rosen jiang
 * OOMPermTest class
 */
package org.rosenjiang.test;

import java.util.ArrayList;
import java.util.List;
import org.objectweb.asm.ClassWriter;
import org.objectweb.asm.Opcodes;

public class OOMPermTest {
    public static void main(String[] args) {
        OOMPermTest o = new OOMPermTest();
        o.oom();
    }

    private void oom() {
        try {
            ClassWriter cw = new ClassWriter(0);
            cw.visit(Opcodes.V1_5, Opcodes.ACC_PUBLIC + Opcodes.ACC_ABSTRACT,
            "org/rosenjiang/test/MyAbsClass", null, "java/lang/Object",
            new String[] {});
            cw.visitField(Opcodes.ACC_PUBLIC + Opcodes.ACC_FINAL + Opcodes.ACC_STATIC, "LESS", "I",
            null, new Integer(-1)).visitEnd();
            cw.visitField(Opcodes.ACC_PUBLIC + Opcodes.ACC_FINAL + Opcodes.ACC_STATIC, "EQUAL", "I",
            null, new Integer(0)).visitEnd();
            cw.visitField(Opcodes.ACC_PUBLIC + Opcodes.ACC_FINAL + Opcodes.ACC_STATIC, "GREATER", "I",
            null, new Integer(1)).visitEnd();
            cw.visitMethod(Opcodes.ACC_PUBLIC + Opcodes.ACC_ABSTRACT, "absTo",
            "(Ljava/lang/Object;)I", null, null).visitEnd();
            cw.visitEnd();
            byte[] b = cw.toByteArray();

            List<ClassLoader> classLoaders = new ArrayList<ClassLoader>();
            while (true) {
                MyClassLoader classLoader = new MyClassLoader();
                classLoader.defineClass("org.rosenjiang.test.MyAbsClass", b);
                classLoaders.add(classLoader);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

不一會兒，控制檯就報錯了。

java.lang.OutOfMemoryError: PermGen space
Dumping heap to java_pid3023.hprof 
Heap dump file created [92593641 bytes in 2.405 secs]
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space

打開java_pid3023.hprof文件，注意看下圖的Classes: 88.1k和Class Loader: 87.7k部分，從這點可看出class loader加載了大量的類。



更進一步分析，點擊上圖中紅框線圈起來的按鈕，選擇Java Basics——Class Loader Explorer功能。打開後能看到下圖所示的界面，第一列是class loader名字；第二列是class loader已定義類(defined classes)的個數，這裏要說一下已定義類和已加載類(loaded classes)了，當需要加載類的時候，相應的class loader會首先把請求委派給父class loader，只有當父class loader加載失敗後，該class loader纔會自己定義並加載類，這就是Java自己的“雙親委派加載鏈”結構；第三列是class loader所加載的類的實例數目。



在Class Loader Explorer這裏，能發現class loader是否加載了過多的類。另外，還有Duplicate Classes功能，也能協助分析重複加載的類，在此就不再截圖了，可以肯定的是MyAbsClass被重複加載了N多次。

最後

其實MAT工具非常的強大，上面故弄玄虛的範例代碼根本用不上MAT的其他分析功能，所以就不再描述了。其實對於OOM不只我列舉的兩種溢出錯誤，還有多種其他錯誤，但我想說的是，對於perm gen，如果實在找不出問題所在，建議使用JVM的-verbose參數，該參數會在後臺打印出日誌，可以用來查看哪個class loader加載了什麼類，例：“[Loaded org.rosenjiang.test.MyAbsClass from org.rosenjiang.test.MyClassLoader]”。
全文完。

概述

在android的開發中，要時刻主要內存的分配和垃圾回收，因爲系統爲每一個dalvik虛擬機分配的內存是有限的，在google的G1中，分配的最大堆大小隻有16M，後來的機器一般都爲24M，實在是少的可憐。這樣就需要我們在開發過程中要時刻注意。不要因爲自己的代碼問題而造成OOM錯誤。

JAVA的內存管理

大家都知道，android應用層是由java開發的，android的davlik虛擬機與jvm也類似，只不過它是基於寄存器的。因此要了解android的內存管理就必須得了解java的內存分配和垃圾回收機制。

在java中，是通過new關鍵字來爲對象分配內存的，而內存的釋放是由垃圾收集器（GC）來回收的，工程師在開發的過程中，不需要顯式的去管理內存。但是這樣有可能在不知不覺中就會浪費了很多內存，最終導致java虛擬機花費很多時間去進行垃圾回收，更嚴重的是造成JVM的OOM。因此，java工程師還是有必要了解JAVA的內存分配和垃圾回收機制。

• 
  
• 內存結構
  

 

上面這張圖是JVM的結構圖，它主要四個部分組成：Class Loader子系統和執行引擎，運行時方法區和本地方法區，我們主要來看下RUNTIME DATA AREA區，也就是我們常說的JVM內存。從圖中可以看出，RUNTIMEDATA AREA區主要由5個部分組成：

• 
  
  

Method Area:被裝載的class的元信息存儲在Method Area中，它是線程共享的 Heap(堆)：一個java虛擬機實例中只存在一個堆空間，存放一些對象信息，它是線程共享的 Java棧： java虛擬機直接對java棧進行兩種操作，以幀爲單位的壓棧和出棧（非線程共享） 程序計數器（非線程共享） 本地方法棧（非線程共享）

• 
  
• JVM的垃圾回收（GC）
  

 

JVM的垃圾原理是這樣的，它把對象分爲年輕代（Young）、年老代（Tenured）、持久代（Perm），對不同生命週期的對象使用不同的垃圾回收算法。

• 
  
• 年輕代(Young)
  

年輕代分爲三個區，一個eden區，兩個Survivor區。程序中生成的大部分新的對象都在Eden區中，當Eden區滿時，還存活的對象將被複制到其中一個Survivor區，當此Survivor區的對象佔用空間滿了時，此區存活的對象又被複制到另外一個Survivor區，當這個Survivor區也滿了的時候，從第一個Survivor區複製過來的並且此時還存活的對象，將被複制到年老代。

• 
  
• 年老代（Tenured）
  

年老代存放的是上面年輕代複製過來的對象，也就是在年輕代中還存活的對象，並且區滿了複製過來的。一般來說，年老代中的對象生命週期都比較長。

• 
  
• 持久代（Perm）
  

用於存放靜態的類和方法，持久代對垃圾回收沒有顯著的影響。

Android中內存泄露監測

在瞭解了JVM的內存管理後，我們再回過頭來看看，在android中應該怎樣來監測內存，從而看在應用中是否存在內存分配和垃圾回收問題而造成內存泄露情況。

在android中，有一個相對來說還不錯的工具，可以用來監測內存是否存在泄露情況：DDMS—Heap

 

使用方法比較簡單：

• 
  
  

選擇DDMS視圖，並打開Devices視圖和Heap視圖 點擊選擇要監控的進程，比如：上圖中我選擇的是system_process 選中Devices視圖界面上的"update heap" 圖標 點擊Heap視圖中的"Cause GC" 按鈕（相當於向虛擬機發送了一次GC請求的操作）

在Heap視圖中選擇想要監控的Type，一般我們會觀察dataobject的 total size的變化，正常情況下total size的值會穩定在一個有限的範圍內，也就說程序中的代碼良好，沒有造成程序中的對象不被回收的情況。如果代碼中存在沒有釋放對象引用的情況，那麼data object的total size在每次GC之後都不會有明顯的回落，隨着操作次數的增加而total size也在不斷的增加。（說明：選擇好data object後，不斷的操作應用，這樣纔可以看出total size的變化）。如果totalsize確實是在不斷增加而沒有回落，說明程序中有沒有被釋放的資源引用。那麼我們應該怎麼來定位呢？

Android中內存泄露定位

Mat(memory analyzer tools)是我們常用的用來定位內存泄露的工具，如果你使用ADT，並且安裝了MAT的eclipse插件，你需要做的是進入DDMS視圖的Devices視圖：

 

點擊"dump HPROF file"按鈕，然後使用MAT分析下載下來的文件。

 

下面列出了存在的問題，點擊detail進去，會列出詳細的，可能會存在問題的代碼：

關於MAT的使用可以參考：http://www.blogjava.net/rosen/archive/2010/06/13/323522.html

這位兄弟寫的比較詳細。

總結

不管是java還是android，都應該瞭解內存分配和垃圾回收機制，工程師要做到寫的代碼中沒有bad code很難，關鍵是在出現問題的時候該怎麼去排查。