分析和定位線上作業(yè) OOM 問題利器-MAT
點(diǎn)擊上方藍(lán)色字體，選擇“設(shè)為星標(biāo)”
本文作者：學(xué)無止境?原文鏈接：https://www.cnblogs.com/duanxz/p/6046055.html在工作中可能會(huì)遇到內(nèi)存溢出這種災(zāi)難性的問題，那么程序肯定是存在問題，找出問題至關(guān)重要，上一篇文章講了jmap命令的使用方法，當(dāng)然用jmap導(dǎo)出的文件我們也看不懂啊，那就交給memory analyzer(mat)這個(gè)工具，讓他幫助我們來觀察程序的內(nèi)存分布情況吧。MAT 不是一個(gè)萬能工具，它并不能處理所有類型的堆存儲(chǔ)文件。但是比較主流的廠家和格式，例如 Sun, HP, SAP 所采用的 HPROF 二進(jìn)制堆存儲(chǔ)文件，以及 IBM 的 PHD 堆存儲(chǔ)文件等都能被很好的解析。下面來看看要怎么做呢，也許對(duì)你有用。官方文檔：http://help.eclipse.org/luna/index.jsp?topic=/org.eclipse.mat.ui.help/welcome.html造成OutOfMemoryError原因一般有2種：1、內(nèi)存泄露，對(duì)象已經(jīng)死了，無法通過垃圾收集器進(jìn)行自動(dòng)回收，通過找出泄露的代碼位置和原因，才好確定解決方案；2、內(nèi)存溢出，內(nèi)存中的對(duì)象都還必須存活著，這說明Java堆分配空間不足，檢查堆設(shè)置大?。?Xmx與-Xms），檢查代碼是否存在對(duì)象生命周期太長、持有狀態(tài)時(shí)間過長的情況。
jmap 命令生成堆信息
jmap?-dump:live,format=b,file=E:/jmap/heap.dump?pid
這樣在E盤的jmap文件夾里會(huì)有一個(gè)map.bin的堆信息文件這樣在E盤的jmap文件夾里會(huì)有一個(gè)map.bin的堆信息文件將堆信息導(dǎo)入到mat中分析
生成分析報(bào)告
mat可以為我們生成多個(gè)報(bào)告：
從上圖可以看到它的大部分功能，在餅圖上,你會(huì)發(fā)現(xiàn)轉(zhuǎn)儲(chǔ)的大小和數(shù)量的類,對(duì)象和類加載器。正確的下面,餅圖給出了一個(gè)印象最大的對(duì)象轉(zhuǎn)儲(chǔ)。移動(dòng)你的鼠標(biāo)看到對(duì)象中的對(duì)象的細(xì)節(jié)檢查在左邊。下面的Action標(biāo)簽中：Histogram可以列出內(nèi)存中的對(duì)象，對(duì)象的個(gè)數(shù)以及大小。
Dominator Tree可以列出那個(gè)線程，以及線程下面的那些對(duì)象占用的空間。
Top consumers通過圖形列出最大的object。
Leak Suspects通過MA自動(dòng)分析泄漏的原因。
Histogram
Class Name ：類名稱，java類名
Objects ：類的對(duì)象的數(shù)量，這個(gè)對(duì)象被創(chuàng)建了多少個(gè)
Shallow Heap ：一個(gè)對(duì)象內(nèi)存的消耗大小，不包含對(duì)其他對(duì)象的引用
Retained Heap ：是shallow Heap的總和，也就是該對(duì)象被GC之后所能回收到內(nèi)存的總和
這兒借助工具提供的regex正則搜索一下我們自己的類，排序后看看哪些相對(duì)是占用比較大的。
左邊可以看到類的詳細(xì)使用，比如所屬包，父類是誰，所屬的類加載器，內(nèi)存地址，占用大小和回收情況等
這兒有個(gè)工具可以根據(jù)自己的需求分組查找，默認(rèn)根據(jù)class分組，類似我們sql里的group by了~~
這里可以看到上面3個(gè)選項(xiàng)，分別生成overview、leak suspects、top components數(shù)據(jù)，但是這兒生成的不是圖表，如果要看圖表在（Overview）中的Action標(biāo)簽里點(diǎn)擊查看。這個(gè)是Overview中的 Heap Dump Overview視圖，從工具欄中點(diǎn)開，這是一個(gè)全局的內(nèi)存占用信息
Dominator Tree
我們可以看到ibatis占了較多內(nèi)存Top consumers
這張圖展示的是占用內(nèi)存比較多的對(duì)象的分布，下面是具體的一些類和占用。
按等級(jí)分布的類使用情況，其實(shí)也就是按使用次數(shù)查看，java.lang.Class被排在第一
還有一張圖是我們比較關(guān)心的，那就是按包名看占用，根據(jù)包我們知道哪些公共用的到j(luò)ar或自己的包占用
這樣就可以看到包和包中哪些類的占用比較高。Leak Suspects
從這份報(bào)告，看到該圖深色區(qū)域被懷疑有內(nèi)存泄漏，可以發(fā)現(xiàn)整個(gè)heap只有79.7M內(nèi)存，深色區(qū)域就占了62%。所以，MAT通過簡單的報(bào)告就說明了項(xiàng)目是有可疑代碼的，具體點(diǎn)開詳情來找到類，
點(diǎn)擊鼠標(biāo)，在List Objects-> with outgoing references下可以查看該類都引用了什么對(duì)象，由此查看是否因?yàn)槠渌麑?duì)象導(dǎo)致的內(nèi)存問題。下面繼續(xù)查看pool的gc ROOT如下圖所示的上下文菜單中選擇 Path To GC Roots -> exclude weak references, 過濾掉弱引用，因?yàn)樵谶@里弱引用不是引起問題的關(guān)鍵。進(jì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?"" .
Keywords
java.util.HashMap$Entry[]
org.apache.catalina.loader.WebappClassLoader?@?0xa34cde8
這段話是在工具中提示的，他告訴我們WebappClassLoader占了19,052,864 字節(jié)的容量，這是tomcat的類加載器，JDK自帶的系統(tǒng)類加載器中占用比較多的是HashMap。這個(gè)其實(shí)比較正常，大家經(jīng)常用map作為存儲(chǔ)容器。除了在上一頁看到的描述外，還有Shortest Paths To the Accumulation Point和Accumulated Objects部分，這里說明了從GC root到聚集點(diǎn)的最短路徑，以及完整的reference chain。觀察Accumulated Objects部分，java.util.HashMap的retained heap(size)最大，所以明顯類實(shí)例都聚集在HashMap中了。
來看看Accumulated Objects by Class區(qū)域，這里能找到被聚集的對(duì)象實(shí)例的類名。java.util.HashMap類上頭條了，被實(shí)例化了5573次，從這兒看出這個(gè)程序不存在什么問題，因?yàn)檫@個(gè)數(shù)字是比較正常的，但是當(dāng)出問題的時(shí)候我們都會(huì)看到比較大的自定義類會(huì)在前面，而且占用是相當(dāng)高。當(dāng)然，mat這個(gè)工具還有很多的用法，這里把我了解的分享給大家，不管如何，最終我們需要得出系統(tǒng)的內(nèi)存占用，然后對(duì)其進(jìn)行代碼或架構(gòu)，服務(wù)器的優(yōu)化措施！歡迎點(diǎn)贊+收藏+轉(zhuǎn)發(fā)朋友圈素質(zhì)三連文章不錯(cuò)？點(diǎn)個(gè)【在看】吧！??
評(píng)論
圖片
表情