ldump分析帮助.docxVIP

用IBM HeapAnalyzer和MOD4J分析Java内存泄漏（2009年7月5日）使用的较多的是Memory Dump Diagnostic for Java (MDD4J)和IBM HeapAnalyzer，这两个工具都能支持几乎所有JDK版本所生成的堆转储文件。先说一下IBM HeapAnalyzer，下载之后首先阅读一下readme，详细写了HeapAnalyzer的使用方法。可以在命令行中输入Java pathjava –Xmx[heapsize] –jar ha26.jar heapdump file来启动工具并加载heapdump文件。对于比较大的heapdump，将-Xmx设置一个较大的值（大于heapdump的大小），来避免加载过程中的OOM。对于64位机器上产生的超大heapdump，个人机器上分析就不大可能了。打开heapdump文件后，我一般点击“Analysis”里的“Tree View”，以树的形式从根节点展示内存对象分配的信息第一行java.lang.ref.Refenrence这个class及它的76个children占用了67%的已用堆大小（31M/46M），它本身仅占用了76bits。双击java.lang.ref.Refenrence，我们可以看到它所引用的两个子节点。其中一个子节点java.lang.ref.Finalizer后的67%指引我们内存泄漏的问题应该在它的引用上。接下去你可以逐级展开，或者右键点击“Locate a leak suspect”，让HeapAnalyzer帮你找到泄漏可能发生的地方。泄漏一般发生在那些拥有“超乎寻常多”的引用（子节点）的class上，正是这些创建后没有释放、累积了成千上百的对象，造成了OutOfMemory。右键中的“Go to the largest drop subtrees”也是以此为原理而设的，它的解释为：“Search for total size drop” will find a size drop between the total size of a parent and the biggest total size of child of the parent.因为出现泄漏的点，每个子节点占用的内存空间不大，但是巨大的数量会导致父节点占用的total size很大。不过反过来寻找到的点都是泄漏发生的地方这种说法是不成立的，否则也不需要我们来分析了。更多细节的内容，可以看这篇PPTMemory Dump Diagnostic for Java (MDD4J)则是IBM Support Assistant（ISA）里的一个工具，可以在ISA里加载。它的使用方法和HeapAnalyzer类似，不过它会自动列出“可疑泄漏点”供分析。所依据的，是“分析算法查找父对象与子对象之间对象大小的显著变化。这些发生显著变化的父对象可能是基于数组的容器对象，它们包含大量不断增大的子对象。”具体的使用方法可以参考《WebSphere Application Server 中的内存泄漏检测与分析:第 2 部分：用于泄漏检测与分析的工具和功能》一文中的实际案例。（不过文中的版本应该比较低，现在能下到的2和3版本有些不同，不过不妨碍使用）.Heapdump工具的使用很简单，难点在于找到“内存泄漏的真正原因”，一般需要通过多个heapdump文件的对比才能找到。比较分析用于对运行内存泄漏应用程序期间（即可用 Java 堆内存流失时）获取的两个内存转储进行分析。在运行泄漏应用程序的早期触发的内存转储被称为基线内存转储，发生泄漏的应用程序运行一段时间（以允许泄漏程度加大）后触发的内存转储被称为主内存转储。在发生了内存泄漏的情况下，主内存转储可能包含大量对象，而这些对象占用的 Java 堆空间量会比基线内存转储大很多。为了获得更好的分析结果，建议使主内存转储的触发点与基线内存转储的触发点在时间上拉开一定距离，从而使总耗用堆大小在两个触发点之间大幅增长。如果发现“主内存转储”中的某个对象数量大大大于“基线内存转储”，那么这个对象一般就是发生泄漏的点。但是要避免在appserver刚启动时就做heapdump，否则会把正常需要分配的对象当作泄漏嫌疑点。比如原先运行3天会发生OOM，那么可以：缩小堆大小，让OOM提早发生；在运行4个小时后每隔4小时手动做一次Heapdump直到OOM发生。这些动作也许不适合在生产环境下进行，可以另建测试环境进行。之前几篇文章中介绍的分析gc log，和本文讲到的分析heapdump，都是脱机分析法。它们的缺陷就是无法找到代码引起的“性能低下”的原因，正如《用HPjtune分析GC日志》里所看到的那样，系统性能很差，但是没有OOM发生