heapdump分析简单总结

详细的材料可以查看IBM的HeapAnalyzer胶片。

本文只是自己的一些简单总结(废话比较多)，重点还是大家基于实际dump文件去积累经验。

就一个工具，大家都掌握好了就可以有更多时间研究其他东西。

heapdump是什么

通常的名字类似heapdump.20150919.162323.43385076.0055.phd，参考ppt的第12页

java堆内存快照(不包括jni，不是c/c++通常说的那个堆)

用来分析oom的原因

heapdump如何生成

参考ppt的第8~12页，通常维护都知道

需要注意的是，大型中间件的dump是挺大的，需要有足够的硬盘空间，否则频繁的dump会导致空间不足引发其他问题。(频繁dump在生产上是可能的事情)

heapdump分析用什么工具

使用IBM HeapAnalyzer(目前最新ha456.jar, 比之前的版本有更多视图，性能更好)

启动方式: java -jar -Xms512m -Xmx3g ha456.jar

通常要文件大小5倍+的内存, 而websphere之类的dump多在500m以上，所以需要64位的大内存机器，用64位的jdk，堆内存开2g以上

工具需要界面，如果大内存64位机器如果只能找到服务器，可以采用远程运行(但受网速影响)。参考”export DISPLAY=192.168.88.71:0.0”设置xmanager的远程界面显示

ha概念要点

本质上是根据对象引用关系生成一个树结构(可以结合gc的原理加深理解)，参考ppt的第14页

结合图例说明

ha关注要点

关注Leak Suspect,这是检测出来的可能的问题点，有时候非常方便。参考ppt的第34~37页

关注内存占用比例较大的对象，ha支持按TotalSize大小顺序排列(如上图)

关注节点数众多的情况，而且基本上是挂靠在容器上的(不大可能一个对象有n多内部变量)，常见的有map,array,list

关注自己的类，com.huawei开头的。ha支持查询，参考ppt的第54~59页。

有多种维度的视图，多摸索，例如Type List就可以根据特定类型的对象数量进行排序，或许可以找到一些小的内存问题。

如果能够拿到javacore,可以进行对比，定位是哪个功能引起的(单靠类名不一定能够识别哪个业务)。

常见的原因

常见的问题原因如下(有交集，并没有严格分类)：

内存设置太低，不过这个几率比较小。一般的web应用内存分配2G还不够，调大也不是办法。

大量的线程泄露(或者某种原因阻塞)，java的线程是系统线程，占用的资源还是可观的，相关的可以看Xss参数。生产一般看到的websphere也就300左右。

查询/导出大量数据, 常见于SQL查询结果没有限制数量、或者在内存中集中写出。

远程调用传输大量数据，常见于cics返回大量数据(其实和上面差不多是一个道理)

上传并处理数据，没有分批分段处理或延后处理。

数据没能及时释放，可能是处理较多的数据或较长的处理流程，不过需要显式释放对象引用的情况是比较少见的。

不过，需要注意的是:

像dbc这样的jni实现可能和这个没什么关系，原因在于64位机器进程空间很大。

像数据库，远程调用等响应慢，是不一定会出现dump问题的。但它会导致线程数增多(同步)，数据(占用内存)未及时处理，从而导致dump。