双剑合并：使用JavaCore和Heapdump定位内存溢出原因
对于B/S架构的J2EE应用系统，应用服务器发生内存溢出(OutOfMemoryError)错误是非常棘手的问题，解决问题的关键是要定位哪里出了问题。一般内存溢出的原因有以下几类:
如：
-Xmx设置的比较小
-Xms设置的过大
sun的jvm没有设置
-XX:MaxPermSize大小等等
由于参数设置问题导致的内存溢出往往容易发现，调整一下参数，问题基本就可以解决。
例如Websphere的某些版本存在很多性能缺陷，某些情况下也会导致内存溢出，打上补丁后，问题基本可以得到解决。
此类问题是内存溢出最常见的原因，解决起来也最麻烦，本文主要描述这类内存溢出问题如何进行分析和定位。
工欲善其事，必先利其器，有了好的工具，解决问题往往能起到事半功倍的作用，很多时候没有工具支持，问题很难解决。
本文主要涉及到2个工具的运用：
分析JavaCore的工具：IBM Thread and Monitor Dump Analyzer for Java。
分析Heapdump的工具：Eclipse Memory Analyzer。
通过这2个工具，一般的内存溢出问题基本可以定位。
在介绍这2个工具之前，先对一些相关概念做下解释说明：
某一时刻Java进程内存的快照，记录当时内存中各对象的存储和引用关系等。Heapdump中不包含对象的调用信息，即无法从Heapdump中看出某个对象是哪段程序代码生成出来的。
某一时刻Java进程中线程的快照，记录当时所有线程的执行堆栈信息等。JavaCore中可以看到各线程都在处理哪些程序代码，可以看到当前Java都在“做什么事”，在线程的执行堆栈中，有代码的调用信息，也有对象生成的相关信息等。
内存溢出一般分两种，内存使用过度和内存泄露。
使用过度指在短时间内急剧耗尽大量内存导致内存溢出。
内存泄露指长时间内，内存逐渐耗尽导致内存溢出，时间可能是几个小时或几天(通过开启详细垃圾回收可以清晰地观察到内存的分配情况)。
Java系统的内存溢出大部分都是由于内存使用过度导致，内存泄露比较少见。本文后面介绍的也都是关于内存使用过度导致内存溢出的分析方法。
对于内存使用过度导致的内存溢出，可以通过Heapdump和JavaCore结合分析定位问题，对于内存泄露，主要还是分析Heapdump。
当Java进程出现内存溢出错误时，通常会生成Heapdump文件和JavaCore文件，例如Websphere部署的web应用，当出现内存溢出时，会在如下目录
/opt/IBM/WebSphere/AppServer/profiles/server1看到出现类似这样的文件：
Heapdump.*.phd文件记录Heapdump信息，javacore.*.txt记录JavaCore信息，一般内存溢出时会出现多个phd文件和JavaCore文件，分析时用其中一个即可。
下面就介绍如何通过工具分析这2个文件，如何通过对这2个文件的分析定位出内存溢出(内存使用过度导致)的原因。
JavaCore的分析工具IBM Thread and Monitor Dump Analyzer for Java(简称JCA)，以图形化的方式展现java线程的堆栈信息及相互关系等。下面是工具使用的截图：
对于Websphere，主要关注WebContainer线程的执行堆栈情况，上图显示了WebContainer:57号线程的执行堆栈。
JavaCore文件本身就是个文本文件，直接通过文本编辑器如editplus也可以打开，下面是用文本编辑器打开JavaCore文件后看到的WebContainer:57号线程的执行堆栈：
可以看到，通过JCA打开JavaCore和通过editplus打开JavaCore，没有本质的区别，只是展现形式有所区别而已，有关JCA工具的具体使用这里不作详细介绍。
分析JavaCore的重点是根据每个线程的堆栈信息找出哪个或哪几个线程导致Java进程的内存溢出，对应线程堆栈中的代码段就是罪魁祸首。
例如，如果通过分析得到WebContainer:57号线程可能导致内存溢出，那么57号线程中的这段代码就是问题所在。
为什么是WebContainer:57号线程有问题，而不是其它线程呢？这就需要结合Heapdump进行综合分析，下面会有详细介绍。
Heapdump的分析工具推荐Eclipse Memory Analyzer(简称MAT)，该工具比IBM的HA(Heap Analyzer)工具更强大，更易使用。下面是工具的使用截图：
该工具可以看到对象占用内存的大小、对象的个数等信息，通过分析占用内存比例最大的对象，可以初步判断是哪个对象导致的内存溢出，有关MAT工具的具体使用这里不作详细介绍。
Heapdump分析的重点是找到占用内存最大的“业务对象”，所谓业务对象，就是和应用业务相关的对象，需要能靠到应用程序上。
例如上图所示，虽然java.lang.String比DicRestrict对象占用的内存要多，但是我们做分析时应该重点关注DicRestrict对象，因为String对象是通用的业务无关对象，可能很多业务对象都会引用它。
Heapdump分析需要结合业务知识，需要相当的开发和业务经验。
JavaCoree和Heapdump的单独分析，都只是看到了事情的一面，通过一定方法将二者有机地结合起来，问题基本就可以水落石出了。
关联方法：
在Heapdump中占用内存多的对象的名称，可能会出现在JavaCore的线程堆栈中。如下面图示：
Heapdump中显示TdsResultSet占用80%以上的内存，JavaCore中的线程堆栈显示executeAdvQury这个业务代码产生了TdsResultSet对象，内存和线程两方面的分析相吻合，所以问题精确定位。
大部分情况下通过对象名称关联可以找到问题所在。
通过Heapdump和JavaCore的综合分析，定位出具体程序代码，接下来就需要开发人员进行进一步的检查和分析，以找出程序的问题，必要时还需要做大量的测试以重现和验证问题。
本文简要介绍了利用Jca和Mat工具进行内存溢出分析的方法，对如何关联JavaCore和Heapdump做了较详细的介绍。
内存溢出的分析是一项比较复杂的工作，有些时候准确定位问题是非常困难的，本文介绍的方法适合于大部分情况，有些时候JavaCore和Heapdump无法完全关联上，此时就需要分析人员具备丰富的经验和足够的能力，以及合理的猜想和推测，这就是内功的修炼了。
......
本文为51Testing软件测试网
第六十四期51测试天地内容
剩余精彩内容请点击下方
阅读原文 查看
往期回顾