Java程序內(nèi)存分析:使用mat工具分析內(nèi)存占用
MAT 不是一個***工具,它并不能處理所有類型的堆存儲文件。但是比較主流的廠家和格式,例如 Sun, HP, SAP 所采用的 HPROF 二進制堆存儲文件,以及 IBM 的 PHD 堆存儲文件等都能被很好的解析。下面來看看要怎么做呢,也許對你有用。官方文檔:http://help.eclipse.org/luna/index.jsp?topic=/org.eclipse.mat.ui.help/welcome.html
造成OutOfMemoryError原因一般有2種:
1、內(nèi)存泄露,對象已經(jīng)死了,無法通過垃圾收集器進行自動回收,通過找出泄露的代碼位置和原因,才好確定解決方案;
2、內(nèi)存溢出,內(nèi)存中的對象都還必須存活著,這說明Java堆分配空間不足,檢查堆設(shè)置大小(-Xmx與-Xms),檢查代碼是否存在對象生命周期太長、持有狀態(tài)時間過長的情況。
1. 用jmap生成堆信息
2. 將堆信息導(dǎo)入到mat中分析
3. 生成分析報告
mat可以為我們生成多個報告:
下面來看看生成的這些數(shù)據(jù)對我們有什么幫助
從上圖可以看到它的大部分功能,在餅圖上,你會發(fā)現(xiàn)轉(zhuǎn)儲的大小和數(shù)量的類,對象和類加載器。
正確的下面,餅圖給出了一個印象***的對象轉(zhuǎn)儲。移動你的鼠標(biāo)一片看到對象中的對象的細(xì)節(jié)檢查在左邊。下面的Action標(biāo)簽中:
-
Histogram可以列出內(nèi)存中的對象,對象的個數(shù)以及大小。
-
Dominator Tree可以列出那個線程,以及線程下面的那些對象占用的空間。
-
Top consumers通過圖形列出***的object。
-
Leak Suspects通過MA自動分析泄漏的原因。
Histogram
-
Class Name : 類名稱,java類名
-
Objects : 類的對象的數(shù)量,這個對象被創(chuàng)建了多少個
-
Shallow Heap :一個對象內(nèi)存的消耗大小,不包含對其他對象的引用
-
Retained Heap :是shallow Heap的總和,也就是該對象被GC之后所能回收到內(nèi)存的總和
一般來說,Shallow Heap堆中的對象是它的大小和保留內(nèi)存大小相同的對象是堆內(nèi)存的數(shù)量時,將釋放對象被垃圾收集。
保留設(shè)置一組主要的對象,例如一個特定類的所有對象,或所有對象的一個特定的類裝入器裝入的類或者只是一群任意對象,是釋放的組對象如果所有對象的主要設(shè)置變得難以接近的。保留設(shè)置包括這些對象以及所有其他對象只能通過這些對象。保留大小是總堆大小中包含的所有對象的保留。摘自eclipse
關(guān)于的詳細(xì)講解,建議大家查看Shallow heap & Retained heap,這是個很重要的概念。
這兒借助工具提供的regex正則搜索一下我們自己的類,排序后看看哪些相對是占用比較大的。
左邊可以看到類的詳細(xì)使用,比如所屬包,父類是誰,所屬的類加載器,內(nèi)存地址,占用大小和回收情況等
#p#
這兒有個工具可以根據(jù)自己的需求分組查找,默認(rèn)根據(jù)class分組,類似我們sql里的group by了~~
這里可以看到上面3個選項,分別生成overview、leak suspects、top components數(shù)據(jù),但是這兒生成的不是圖表,如果要看圖表在(Overview)中的Action標(biāo)簽里點擊查看。
這個是Overview中的 Heap Dump Overview視圖,從工具欄中點開,這是一個全局的內(nèi)存占用信息
Used heap dump | 79.7 MB |
Number of objects | 1,535,626 |
Number of classes | 8,459 |
Number of class loaders | 74 |
Number of GC roots | 2,722 |
Format | hprof |
JVM version | |
Time | 格林尼治標(biāo)準(zhǔn)時間+0800上午9時20分37秒 |
Date | 2014-7-2 |
Identifier size | 32-bit |
File path | E:\jmap\map.bin |
File length | 108,102,005 |
|
然后可以點開SystemProperties和Thread Overview進行查看,我這里就不貼了內(nèi)容比較多。
Dominator Tree
我們可以看到ibatis占了較多內(nèi)存
Top consumers
這張圖展示的是占用內(nèi)存比較多的對象的分布,下面是具體的一些類和占用。
按等級分布的類使用情況,其實也就是按使用次數(shù)查看,java.lang.Class被排在***
還有一張圖是我們比較關(guān)心的,那就是按包名看占用,根據(jù)包我們知道哪些公共用的到j(luò)ar或自己的包占用
這樣就可以看到包和包中哪些類的占用比較高。
#p#
Leak Suspects
從這份報告,看到該圖深色區(qū)域被懷疑有內(nèi)存泄漏,可以發(fā)現(xiàn)整個heap只有79.7M內(nèi)存,深色區(qū)域就占了62%。所以,MAT通過簡單的報告就說明了項目是有可疑代碼的,具體點開詳情來找到類,
點擊鼠標(biāo),在List Objects-> with outgoing references下可以查看該類都引用了什么對象,由此查看是否因為其他對象導(dǎo)致的內(nèi)存問題。
下面繼續(xù)查看pool的gc ROOT
如下圖所示的上下文菜單中選擇 Path To GC Roots -> exclude weak references, 過濾掉弱引用,因為在這里弱引用不是引起問題的關(guān)鍵。
進入查看即可,我這兒的代碼沒有問題,就不用貼了。
The classloader/component "org.apache.catalina.loader.WebappClassLoader @ 0xa34cde8" occupies 19,052,864 (22.80%) bytes. The memory is accumulated in one instance of "java.util.HashMap$Entry[]" loaded by "<system class loader>".
Keywords
java.util.HashMap$Entry[]
org.apache.catalina.loader.WebappClassLoader @ 0xa34cde8
這段話是在工具中提示的,他告訴我們WebappClassLoader占了19,052,864 字節(jié)的容量,這是tomcat的類加載器,JDK自帶的系統(tǒng)類加載器中占用比較多的是HashMap。這個其實比較正常,大家經(jīng)常用map作為存儲容器。
除了在上一頁看到的描述外,還有Shortest Paths To the Accumulation Point和Accumulated Objects部分,這里說明了從GC root到聚集點的最短路徑,以及完整的reference chain。觀察Accumulated Objects部分,java.util.HashMap的retained heap(size)***,所以明顯類實例都聚集在HashMap中了。
來看看Accumulated Objects by Class區(qū)域,這里能找到被聚集的對象實例的類名。java.util.HashMap類上頭條了,被實例化了5573次,從這兒看出這個程序不存在什么問題,因為這個數(shù)字是比較正常的,但是當(dāng)出問題的時候我們都會看到比較大的自定義類會在前面,而且占用是相當(dāng)高。
當(dāng)然,mat這個工具還有很多的用法,這里把我了解的分享給大家,不管如何,最終我們需要得出系統(tǒng)的內(nèi)存占用,然后對其進行代碼或架構(gòu),服務(wù)器的優(yōu)化措施!
參考文獻:
http://www.eclipse.org/mat/about/screenshots.php
http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-ma/