問題描述

對(duì)于B/S架構(gòu)的J2EE應(yīng)用系統(tǒng)，應(yīng)用服務(wù)器發(fā)生內(nèi)存溢出(OutOfMemoryError)錯(cuò)誤是非常棘手的問題，解決問題的關(guān)鍵是要定位哪里出了問題。一般內(nèi)存溢出的原因有以下幾類:

Jvm內(nèi)存參數(shù)設(shè)置不合理

如：

• -Xmx設(shè)置的比較小
• -Xms設(shè)置的過大
• sun的jvm沒有設(shè)置
• -XX:MaxPermSize大小等等

由于參數(shù)設(shè)置問題導(dǎo)致的內(nèi)存溢出往往容易發(fā)現(xiàn)，調(diào)整一下參數(shù)，問題基本就可以解決。

應(yīng)用服務(wù)器缺少必要的補(bǔ)丁

例如Websphere的某些版本存在很多性能缺陷，某些情況下也會(huì)導(dǎo)致內(nèi)存溢出，打上補(bǔ)丁后，問題基本可以得到解決。

應(yīng)用程序代碼存在缺陷

此類問題是內(nèi)存溢出最常見的原因，解決起來也最麻煩，本文主要描述這類內(nèi)存溢出問題如何進(jìn)行分析和定位。

解決方案

工欲善其事，必先利其器，有了好的工具，解決問題往往能起到事半功倍的作用，很多時(shí)候沒有工具支持，問題很難解決。

本文主要涉及到2個(gè)工具的運(yùn)用：

• 分析JavaCore的工具：IBM Thread and Monitor Dump Analyzer for Java。
• 分析Heapdump的工具：Eclipse Memory Analyzer。

通過這2個(gè)工具，一般的內(nèi)存溢出問題基本可以定位。

在介紹這2個(gè)工具之前，先對(duì)一些相關(guān)概念做下解釋說明：

Heapdump

某一時(shí)刻Java進(jìn)程內(nèi)存的快照，記錄當(dāng)時(shí)內(nèi)存中各對(duì)象的存儲(chǔ)和引用關(guān)系等。Heapdump中不包含對(duì)象的調(diào)用信息，即無法從Heapdump中看出某個(gè)對(duì)象是哪段程序代碼生成出來的。

JavaCore

某一時(shí)刻Java進(jìn)程中線程的快照，記錄當(dāng)時(shí)所有線程的執(zhí)行堆棧信息等。JavaCore中可以看到各線程都在處理哪些程序代碼，可以看到當(dāng)前Java都在“做什么事”，在線程的執(zhí)行堆棧中，有代碼的調(diào)用信息，也有對(duì)象生成的相關(guān)信息等。

兩種內(nèi)存溢出

內(nèi)存溢出一般分兩種，內(nèi)存使用過度和內(nèi)存泄露。

• 使用過度指在短時(shí)間內(nèi)急劇耗盡大量內(nèi)存導(dǎo)致內(nèi)存溢出。
• 內(nèi)存泄露指長時(shí)間內(nèi)，內(nèi)存逐漸耗盡導(dǎo)致內(nèi)存溢出，時(shí)間可能是幾個(gè)小時(shí)或幾天(通過開啟詳細(xì)垃圾回收可以清晰地觀察到內(nèi)存的分配情況)。

Java系統(tǒng)的內(nèi)存溢出大部分都是由于內(nèi)存使用過度導(dǎo)致，內(nèi)存泄露比較少見。本文后面介紹的也都是關(guān)于內(nèi)存使用過度導(dǎo)致內(nèi)存溢出的分析方法。

對(duì)于內(nèi)存使用過度導(dǎo)致的內(nèi)存溢出，可以通過Heapdump和JavaCore結(jié)合分析定位問題，對(duì)于內(nèi)存泄露，主要還是分析Heapdump。

當(dāng)Java進(jìn)程出現(xiàn)內(nèi)存溢出錯(cuò)誤時(shí)，通常會(huì)生成Heapdump文件和JavaCore文件，例如Websphere部署的web應(yīng)用，當(dāng)出現(xiàn)內(nèi)存溢出時(shí)，會(huì)在如下目錄

/opt/IBM/WebSphere/AppServer/profiles/server1看到出現(xiàn)類似這樣的文件：

Heapdump.*.phd文件記錄Heapdump信息，javacore.*.txt記錄JavaCore信息，一般內(nèi)存溢出時(shí)會(huì)出現(xiàn)多個(gè)phd文件和JavaCore文件，分析時(shí)用其中一個(gè)即可。

下面就介紹如何通過工具分析這2個(gè)文件，如何通過對(duì)這2個(gè)文件的分析定位出內(nèi)存溢出(內(nèi)存使用過度導(dǎo)致)的原

1. 分析 javacore

Javacore 的分析工具 IBM Thread and Monitor Dump Analyzer for Java(簡稱 JCA)，以圖形化的方式展現(xiàn) java 線程的堆棧信息及相互關(guān)系等。下面是工具使用的截圖：

對(duì)于 Websphere，主要關(guān)注 WebContainer 線程的執(zhí)行堆棧情況，上圖顯示W(wǎng)ebContainer:57 號(hào)線程的執(zhí)行堆棧。Javacore 文件本身就是個(gè)文本文件，直接通過文本編輯器如 editplus 也可以打開，下面是用文本編輯器打開 javacore 文件后看到的WebContainer:57 號(hào)線程的執(zhí)行堆棧：

可以看到，通過 JCA 打開 javacore 和通過 editplus 打開 javacore，沒有本質(zhì)的區(qū)別，只是展現(xiàn)形式有所區(qū)別而已，有關(guān) JCA 工具的具體使用這里不作詳細(xì)介紹。分析 javacore的重點(diǎn)是根據(jù)每個(gè)線程的堆棧信息找出哪個(gè)或哪幾個(gè)線程導(dǎo)致 java 進(jìn)程的內(nèi)存溢出，對(duì)應(yīng)線程堆棧中的代碼段就是罪魁禍?zhǔn)住＠?，如果通過分析得到 WebContainer:57 號(hào)線程可能導(dǎo)致內(nèi)存溢出，那么 57 號(hào)線程中的這段代碼就是問題所在。

為什么是 WebContainer:57 號(hào)線程有問題，而不是其它線程呢？這就需要結(jié)合heapdump 進(jìn)行綜合分析，下面會(huì)有詳細(xì)介紹。

2. 分析 Heapdump

Heapdump 的分析工具推薦 Eclipse Memory Analyzer(簡稱 MAT)，該工具比 IBM 的HA(Heap Analyzer)工具更強(qiáng)大，更易使用。下面是工具的使用截圖：

該工具可以看到對(duì)象占用內(nèi)存的大小、對(duì)象的個(gè)數(shù)等信息，通過分析占用內(nèi)存比例最大的對(duì)象，可以初步判斷是哪個(gè)對(duì)象導(dǎo)致的內(nèi)存溢出，有關(guān) MAT 工具的具體使用這里不作詳細(xì)介紹。heapdump 分析的重點(diǎn)是找到占用內(nèi)存最大的“業(yè)務(wù)對(duì)象”，所謂業(yè)務(wù)對(duì)象，就是和應(yīng)用業(yè)務(wù)相關(guān)的對(duì)象，需要能靠到應(yīng)用程序上。例如上圖所示，雖然java.lang.String 比 DicRestrict 對(duì)象占用的內(nèi)存要多，但是我們做分析時(shí)應(yīng)該重點(diǎn)關(guān)注DicRestrict 對(duì)象，因?yàn)?String 對(duì)象是通用的業(yè)務(wù)無關(guān)對(duì)象，可能很多業(yè)務(wù)對(duì)象都會(huì)引用它。Heapdump 分析需要結(jié)合業(yè)務(wù)知識(shí)，需要相當(dāng)?shù)拈_發(fā)和業(yè)務(wù)經(jīng)驗(yàn)。

3. 雙劍合并

Javacore 和 heapdump 的單獨(dú)分析，都只是看到了事情的一面，通過一定方法將二者有機(jī)的結(jié)合起來，問題基本就可以水落石出了。