前言
在平時(shí)開發(fā)、測試過程中、甚至是生產(chǎn)環(huán)境中，有時(shí)會(huì)遇到OutOfMemoryError，Java堆溢出了，這表明程序有嚴(yán)重的問題。我們需要找造成OutOfMemoryError原因。一般有兩種情況：
1、內(nèi)存泄露，對(duì)象已經(jīng)死了，無法通過垃圾收集器進(jìn)行自動(dòng)回收，通過找出泄露的代碼位置和原因，才好確定解決方案；
2、內(nèi)存溢出，內(nèi)存中的對(duì)象都還必須存活著，這說明Java堆分配空間不足，檢查堆設(shè)置大?。?Xmx與-Xms），檢查代碼是否存在對(duì)象生命周期太長、持有狀態(tài)時(shí)間過長的情況。
以上是處理Java堆問題的思路，具體是怎么進(jìn)行分析，這里介紹的是使用Eclipse Memory Analyzer tool(MAT)工具分析的過程。
生成dump文件
通過jvm參數(shù)--XX:-HeapDumpOnOutOfMemoryError可以讓JVM在出現(xiàn)內(nèi)存溢出是Dump出當(dāng)前的內(nèi)存轉(zhuǎn)儲(chǔ)快照；
或者，用jmap生產(chǎn)dump文件，win通過任務(wù)管理器查看tomcat的進(jìn)程pid，linux用ps命令查看進(jìn)程pid,然后用jmap命令（Java5：jmap -heap:format=b <pid>；Java6：jmap -dump:format=b,file=HeapDump.bin <pid>）。
我這里使用的是，我一生產(chǎn)環(huán)境項(xiàng)目，運(yùn)行一段時(shí)間大概3周的樣子，就會(huì)報(bào)OutOfMemoryError。（ps：這個(gè)項(xiàng)目出現(xiàn)這種情況已經(jīng)有好長一段時(shí)間了，我們之前的做法是定期的重啟tomcat，沒有去分析它的原因。）JDK64位主要參數(shù)：-Xmx3078M -Xms3078M -XX:PermSize=1024M -XX:MaxPermSize=1024M，內(nèi)存還是蠻大的。
MAT安裝與介紹
下載地址：http://www.eclipse.org/mat/downloads.php。
通過MAT打開dump出來的內(nèi)存文件，打開后如下圖：
從上圖可以看到它的大部分功能。
1. Histogram可以列出內(nèi)存中的對(duì)象，對(duì)象的個(gè)數(shù)以及大小。
2. Dominator Tree可以列出那個(gè)線程，以及線程下面的那些對(duì)象占用的空間。
3.Top consumers通過圖形列出最大的object。
4.Leak Suspects通過MA自動(dòng)分析泄漏的原因。
Histogram如下圖：
Objects:類的對(duì)象的數(shù)量。
Shallow size：就是對(duì)象本身占用內(nèi)存的大小，不包含對(duì)其他對(duì)象的引用，也就是對(duì)象頭加成員變量（不是成員變量的值）的總和。
Retained size：是該對(duì)象自己的shallow size，加上從該對(duì)象能直接或間接訪問到對(duì)象的shallow size之和。換句話說，retained size是該對(duì)象被GC之后所能回收到內(nèi)存的總和。 我們發(fā)現(xiàn)ThreadLocal和bingo.persister.dao.Daos類的對(duì)象占用了很多空間。
Dominator Tree如下圖：
我們發(fā)現(xiàn)quartz的定時(shí)器的工作線程（10個(gè)）占了很多的內(nèi)存空間
Top consumers如下圖：
這里顯示了內(nèi)存中最大的對(duì)象有哪些，他們對(duì)應(yīng)的類是哪些，類加載器classloader是哪些。
有些時(shí)候，我們?cè)谶@里就可以看到代碼泄露的位置。
Leak Suspects如下圖：
從那個(gè)餅圖，該圖深色區(qū)域被懷疑有內(nèi)存泄漏，可以發(fā)現(xiàn)整個(gè)heap才250M內(nèi)存，深色區(qū)域就占了34%。后面的描述，告訴我們quartz線程占用了大量內(nèi)存，并指出system class loader加載的"java.lang.ThreadLocal"實(shí)例的內(nèi)存中聚集（消耗空間），并建議用關(guān)鍵字"java.lang.ThreadLocal$ThreadLocalMap$Entry[]"進(jìn)行檢查。所以，MAT通過簡單的報(bào)告就說明了問題所在。
通過Leak Suspects的Problem Suspect 1點(diǎn)擊【Details ?】，
如下圖如下圖所示的上下文菜單中選擇 List objects -> with outgoning references, 查看ThreadLocal都應(yīng)用了些什么對(duì)象。
現(xiàn)在看到ThreadLocal中引用的對(duì)象如下圖：
是dao對(duì)象
ps：該dao對(duì)象包含一個(gè)輕量級(jí)的ORM關(guān)系內(nèi)容，所以Retained size比較大。
下面繼續(xù)查看dao的gc ROOT
如下圖所示的上下文菜單中選擇 Path To GC Roots -> exclude weak references, 過濾掉弱引用，因?yàn)樵谶@里弱引用不是引起問題的關(guān)鍵。
從下圖中，可以看到在org.quartz.simpl.SimpleThreadPool中保存了daos的引用。所以可以得出是是因?yàn)槎〞r(shí)器在運(yùn)行的過程中持有大量的Daos對(duì)象應(yīng)起了內(nèi)存泄露。為什么會(huì)有那么多的Daos呢,Daos不是一個(gè)無狀態(tài)的單例的、可以重用的嗎？繼續(xù)查看spring配置文件發(fā)現(xiàn)Daos的bean配置成scope="prototype"，導(dǎo)致定時(shí)任務(wù)又是每次調(diào)用都生產(chǎn)新的Daos實(shí)例。由于是Daos是無狀態(tài)的，修改為單例的，問題解決。
以上是通過MAT分析Tomcat應(yīng)用程序，找到內(nèi)存泄露的原因，并解決。
