內(nèi)存分析工具M(jìn)AT的使用方法

MAT工具介紹

工欲善其事必先利其器，學(xué)會使用工具也是一種本領(lǐng)。本篇文章就把自己之前工作中用到的一個內(nèi)存分析工具給大家介紹下。

內(nèi)存分析工具M(jìn)AT(Memory Analyzer Tool)是一款 JVM 的內(nèi)存分析工具，在實際的工作中可以幫助我們解決生成上內(nèi)存占用過高等問題。

我之前用 MAT 是在 eclipse上使用，前者是后者的一個插件。后來換到 IDEA 才知道原來 MAT 也有獨(dú)立的可運(yùn)行版本。它的下載地址如下：

http://www.eclipse.org/mat/downloads.php

測試代碼

我們先準(zhǔn)備一段簡單的代碼，這個代碼會導(dǎo)致 JVM 堆內(nèi)存溢出，方便我們演示 MAT 的效果。

public static void main(String[] args) throws InterruptedException {
        Map<String,Tom> map = new HashMap<String,Tom>();
        int counter = 1;
        while(true) {
            Thread.sleep(10);
            Tom tom = new Tom();
            String [] friends = new String[counter];
            for (int i = 0; i < friends.length; i++) {
                friends[i] = "friends"+i;
            }
            tom.setAge(counter);
            tom.setName("tom"+counter);
            tom.setFriends(friends);
            map.put(tom.getName(),tom);
            if(counter%100==0)
                System.out.println("put"+counter);
            counter++;
        }
    }

很好理解的一段代碼，一個無限循環(huán)，不斷的往map里添加名為Tom的對象，而且每次循環(huán)new出來的對象的friends屬性還在不斷的擴(kuò)大。

然后我們使用啟動下面這個啟動參數(shù)運(yùn)行代碼，

-Xms200m -Xmx200m  -XX:+HeapDumpOnOutOfMemoryError

參數(shù)指定了堆內(nèi)存大小是200m，這個大小我們的測試代碼很快就會用完，然后報錯。

啟動代碼，運(yùn)行一段時間后報錯如下，

java.lang.OutOfMemoryError: GC overhead limit exceeded
Dumping heap to java_pid1398.hprof ...
Heap dump file created [239632332 bytes in 0.865 secs]

從這個報錯我們可以獲取幾個信息，首先是錯誤類型是內(nèi)存溢出，原因是超出了GC的限制。

其次，我們看到程序出錯時的內(nèi)存快照 dump 到了一個名為 java_pid1398.hprof 的文件中了。這個文件就是可以用于 MAT 工具分析的dump文件。

除了上面的通過 -XX:+HeapDumpOnOutOfMemoryError 參數(shù)來dump內(nèi)存文件之外， 還可以通過 jmap 命令來導(dǎo)出的內(nèi)存快照。這里不做詳述了。

內(nèi)存分析

我們現(xiàn)在根據(jù) MAT 的分析，從幾個維度來分析下代碼中的問題。

MAT 工具打開前面的 dump 文件，會先看到下面這種圖，

從預(yù)覽圖，可以看到有個應(yīng)用占用了總的堆內(nèi)存的大部分，高達(dá)184M（程序運(yùn)行分配的堆內(nèi)存是200M）。說明這個應(yīng)用肯定有問題，值得我們繼續(xù)往下分析。

我們先看看工具給我們的一個判斷，找到 Leak Suspects，點擊去。

從描述上看到，主線程有個本地變量占用了很大內(nèi)存，這個變量是 HashMap 的實例。

哈哈，根據(jù)上面的代碼，不得不說 MAT 還是很牛叉的，對于內(nèi)存泄漏點定位的很準(zhǔn)確。

不過有時候，我們還是需要手動分析下我們還是回到之前的預(yù)覽頁面，找到 Histogram 點進(jìn)去，如下圖：

shallow heap 指的是對象自身占用的內(nèi)存大小，不包括它引用的對象。
針對非數(shù)組類型的對象，它的大小就是對象與它所有的成員變量大小的總和。當(dāng)然這里面還會包括一些java語言特性的數(shù)據(jù)存儲單元。
針對數(shù)組類型的對象，它的大小是數(shù)組元素對象的大小總和。

我們看到排在前面的是占用內(nèi)存比較多的，
char[] 這個明顯是String里引用造成的（string里用char[] 存儲數(shù)據(jù)），我們之間來看String是被誰引用的，

很清晰，Tom對象的friends屬性消耗了很多內(nèi)存。

這里說明下，

• with incoming references 表示的是 當(dāng)前查看的對象，被外部應(yīng)用

• with outGoing references 表示的是 當(dāng)前對象，引用了外部對象

同理，我們可以繼續(xù)分析下面幾個類，最終都會定位到內(nèi)存吃緊的原因是 hashmap 里短時間塞了大量的 Tom 對象撐爆了內(nèi)存。