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。