用IBM HeapAnalyzer 和MOD4J 分析Java 内存泄漏（2009 年7 月5 日） 使用的较多的是Memory Dump Diagnostic for Java (MDD4J)和IBM HeapAnalyzer，这两个工具都能支持几乎所有JDK 版本所生成的堆转储文件。 先说一下 IBM HeapAnalyzer，下载之后首先阅读一下 readme，详细写了 HeapAnalyzer 的使用方法。可以在命令行中输入java –Xmx[heapsize] –jar ha26.jar 来启动工具并加载 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 很大。不过反过来寻找到的点都是泄漏发生的地方这种说法是不成立的，否则也不需要我们来分析了。 更多细节的内容，可以看这篇 PPT Memory Dump Diagnostic for Java (MDD4J)则是IBM Support Assistant（ISA）里的一个工具，可以在ISA 里加载。它的使用方法和 HeapAnalyzer 类似，不过它会自动列出“可疑泄漏点”供分析。所依据的，是“分析算法查找父对象与子对象之间对象大小的显著变化。这些发生显著变化的父对象可能是基于数组的容器对象，它们包含...
