http://jingyan.baidu.com/article/ce09321b620a3d2bff858ff5.html
简单使用：
分析三步曲：
通常我们都会采用下面的“三步曲”来分析内存泄露问题：
首先，对问题发生时刻的系统内存状态获取一个整体印象。
第二步，找到最有可能导致内存泄露的元凶，通常也就是消耗内存最多的对象
接下来，进一步去查看这个内存消耗大户的具体情况，看看是否有什么异常的行为。
下面将用一个基本的例子来展示如何采用“三步曲”来查看生产的分析报告。
1.查看报告之一：内存消耗的整体状况
在报告上最醒目的就是一张简洁明了的饼图，从图上我们可以清晰地看到一个可疑对象消耗了系统 99% 的内存。
在图的下方还有对这个可疑对象的进一步描述。我们可以看到内存是由 java.util.Vector 的实例消耗的，com.ibm.oti.vm.BootstrapClassLoader 负责这个对象的加载。这段描述非常短，但我相信您已经可以从中找到很多线索了，比如是哪个类占用了绝大多数的内存，它属于哪个组件等等。
接下来，我们应该进一步去分析问题，为什么一个 Vector 会占据了系统 99% 的内存，谁阻止了垃圾回收机制对它的回收。
查看报告之二：分析问题的所在
首先我们简单回顾下 JAVA 的内存回收机制，内存空间中垃圾回收的工作由垃圾回收器 (Garbage Collector,GC) 完成的，它的核心思想是：对虚拟机可用内存空间，即堆空间中的对象进行识别，如果对象正在被引用，那么称其为存活对象，反之，如果对象不再被引用，则为垃圾对象，可以回收其占据的空间，用于再分配。
在垃圾回收机制中有一组元素被称为根元素集合，它们是一组被虚拟机直接引用的对象，比如，正在运行的线程对象，系统调用栈里面的对象以及被 system class loader 所加载的那些对象。堆空间中的每个对象都是由一个根元素为起点被层层调用的。因此，一个对象还被某一个存活的根元素所引用，就会被认为是存活对象，不能被回收，进行内存释放。因此，我们可以通过分析一个对象到根元素的引用路径来分析为什么该对象不能被顺利回收。如果说一个对象已经不被任何程序逻辑所需要但是还存在被根元素引用的情况，我们可以说这里存在内存泄露。
现在，让我们开始真正的寻找内存泄露之旅，点击“Details ”链接，可以看到如图 8 所示对可疑对象 1 的详细分析报告。
我们查看下从 GC 根元素到内存消耗聚集点的最短路径：我们可以很清楚的看到整个引用链，内存聚集点是一个拥有大量对象的集合，如果你对代码比较熟悉的话，相信这些信息应该能给你提供一些找到内存泄露的思路了。
接下来，我们再继续看看，这个对象集合里到底存放了什么，为什么会消耗掉如此多的内存。在这张图上，我们可以清楚的看到，这个对象集合中保存了大量 Person 对象的引用，就是它导致的内存泄露。
https://wenku.baidu.com/view/bc5b6b8dcaaedd3382c4d3c8.html
详细教程：
1. Heap Dump
例子：
Heap Dump是一个Java进程在某个时间点上的内存快照。Heap Dump是有着多种格式的。不过总体上Heap Dump在触发快照的时候都保存了java对象和类的信息。通常在写Heap Dump文件前会触发一次FullGC，所以Heap Dump文件中保存的是FullGC后留下的对象信息。
Memory Analyzer可以用来处理HPROF二进制Heap Dump文件、IBM系统dump文件（经过处理后）、以及来自各个平台上的 IBM portable Heap Dumps (PHD)文件。
一般在Heap Dump文件中可以获取到（这仍然取决于Heap Dump文件的类型）如下信息：
对象信息：类、成员变量、直接量以及引用值；
类信息：类加载器、名称、超类、静态成员；
Garbage Collections Roots：JVM可达的对象；
线程栈以及本地变量：获取快照时的线程栈信息，以及局部变量的详细信息。
Heap Dump文件中并不包含内存分配信息，所以通常无法通过Heap Dump文件解决是谁以及在哪里创建了哪些对象这样的问题。
