使用Memory Analyzer Tool（MAT）Eclipse插件分析内存泄露

果使用DDMS确实发现了我们程序中存在内存泄露，那如何定位到具体出现问题的代码片段，最终找到问题所在呢？如果从头到尾分析代码逻辑，那肯定会把人逼疯，特别是在维护别人写的代码的时候。这里介绍一个极好的内存分析工具Memory Analyzer Tool(MAT)。

1、在Eclipse中安装和使用MAT步骤

      MAT是一个Eclipse插件，同时也有单独的RCP客户端。 如果安装Eclipse插件（更方便使用，本文介绍的是使用Eclipse插件）。使      用http://download.eclipse.org/mat/1.2/update-site/进行安装。 也可以在http://www.eclipse.org/mat/downloads.php下载相应的操作系统的RCP客户端。

2、使用命令转换.hprof文件

      如：D:\android-sdk-windows\tools>hprof-conv 6.hprof 7.hprof

3、使用MAT打开并导入.hprof文件

安装完成后切换到Memory Analyzer视图。在Eclipse的左上角有Open Heap Dump按钮，按照刚才说的路径找到java_pid3600.hprof文件并打开。解析hprof文件会花些时间，然后会弹出向导，直接Finish即可。稍后会看到下图所示的界面。



MAT工具分析了heap dump后在界面上非常直观的展示了一个饼图，该图深色区域被怀疑有内存泄漏，可以发现整个heap才64M内存，深色区域就占了99.5%。接下来是一个简短的描述，告诉我们main线程占用了大量内存，并且明确指出system class loader加载的"java.lang.Thread"实例有内存聚集，并建议用关键字"java.lang.Thread"进行检查。所以，MAT通过简单的两句话就说明了问题所在，就算使用者没什么处理内存问题的经验。在下面还有一个"Details"链接，在点开之前不妨考虑一个问题：为何对象实例会聚集在内存中，为何存活（而未被GC）？是的——Strong Ref，那么再走近一些吧。



点击了"Details"链接之后，除了在上一页看到的描述外，还有Shortest Paths To the Accumulation Point和Accumulated Objects部分，这里说明了从GC root到聚集点的最短路径，以及完整的reference chain。观察Accumulated Objects部分，java.util.HashMap和java.lang.Object[1000000]实例的retained heap(size)最大，在上一篇文章中我们知道retained heap代表从该类实例沿着reference chain往下所能收集到的其他类实例的shallow heap(size)总和，所以明显类实例都聚集在HashMap和Object数组中了。这里我们发现一个有趣的现象，既Object数组的shallow heap和retained heap竟然一样，通过Shallow and retained sizes一文可知，数组的shallow heap和一般对象（非数组）不同，依赖于数组的长度和里面的元素的类型，对数组求shallow heap，也就是求数组集合内所有对象的shallow heap之和。好，再来看org.rosenjiang.bo.Pilot对象实例的shallow heap为何是16，因为对象头是8字节，成员变量int是4字节、String引用是4字节，故总共16字节。