在上文中，卸载Agent之后，使用jmap -histo:live pid命令验证执行FGC，相关Class是否会被回收，结果遇到了一些问题，最终通过MAT内存分析才定位到了问题。
安装MAT
MAT是eclipse中的一个插件，不过也提供了独立的版本，在IDEA风靡的今天，建议直接使用独立版本，官网下载地址 http://www.eclipse.org/mat/downloads.php ，根据操作系统版本下载最新的MAT
配置MAT
找到MemoryAnalyzer.ini文件，该文件里面有个Xmx参数，该参数表示最大内存占用量，默认为1024m，根据堆转储文件大小修改该参数即可。
获取堆转储文件
1、如果想主动获取，可以使用jamp命令，对于部署到服务器上的程序可以采用这种方式，获取堆转储文件后scp到本地，然后本地分析。
jmap -dump:format=b,file=<dumpfile.hprof> <pid>
2、如果想在发生内存溢出的时候，自动dump，需要添加下面参数
-XX:+HeapDumpOnOutOfMemoryError
使用MAT
打开MAT之后，加载dump文件，差不多就下面这样的界面。
一般用到比较多的2个功能
1、Histogram
2、Leak Suspects
Histogram
这个功能主要是查看类和对象关系，对象和对象之间的关系，用来定位哪些对象在FGC之后还活着，哪些对象占大部分内存。
1、点开Histogram，可列出每一个类的实例数，支持正则表达式查找，也可以计算出该类所有对象的retained size。
Shallow Heap就是对象本身占用内存的大小，不包含其引用的对象内存，实际分析中作用不大。常规对象（非数组）的ShallowSize由其成员变量的数量和类型决定。数组的shallow size有数组元素的类型（对象类型、基本类型）和数组长度决定。对象成员都是些引用，真正的内存都在堆上，看起来是一堆原生的byte[], char[], int[]，对象本身的内存都很小。
Retained Heap值的计算方式是将Retained Set（当该对象被回收时那些将被GC回收的对象集合）中的所有对象大小叠加。或者说，因为X被释放，导致其它所有被释放对象（包括被递归释放的）所占的heap大小。
Retained Heap例子:
一个ArrayList对象持有100个对象，每一个占用16 bytes，如果这个list对象被回收，那么其中100个对象也可以被回收，可以回收16*100 + X的内存，X代表ArrayList的shallow大小。
所以，RetainedHeap可以更精确的反映一个对象实际占用的大小。
2、选择一个Class，右键选择List objects > with incoming references
在新页面会显示通过这个class创建的对象信息
3、选择一个对象，右键选择Path to GC Roots > ****，通常在排查内存泄漏的时候，我们会选择exclude all phantom/weak/soft etc.references,
意思是查看排除虚引用/弱引用/软引用等的引用链，因为被虚引用/弱引用/软引用的对象可以直接被GC给回收，我们要看的就是某个对象否还存在Strong 引用链（在导出HeapDump之前要手动出发GC来保证），如果有，则说明存在内存泄漏，然后再去排查具体引用。
这时会拿到GC Roots到该对象的路径，通过对象之间的引用，可以清楚的看出这个对象没有被回收的原因，然后再去定位问题。
假如说上面对象此时本来应该是被GC掉的，简单的办法就是将其中的某处置为null或者remove掉，使其到GC Root无路径可达，处于不可触及状态，垃圾回收器就可以回收了。
Leak Suspects
Leak Suspects 界面提示可能存在内存的泄露。
然后接着，是问题一的描述，列出了一些比较大的实例。
点击Details可以看到细节信息
点开Details进入详情页面，在详情页面Shortest Paths To the Accumulation Point表示GC root到内存消耗聚集点的最短路径，如果某个内存消耗聚集点有路径到达GC root，则该内存消耗聚集点不会被当做垃圾被回收。
内存快照对比
为了更有效率的找出内存泄露的对象，一般会获取两个堆转储文件（先dump一个，隔段时间再dump一个），通过对比后的结果可以很方便定位。
