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

MAT是一个Eclipse插件，同时也有单独的RCP客户端。

如果安装Eclipse插件（更方便使用，本文介绍的是使用Eclipse插件）。使用http://download.eclipse.org/mat/1.2/update-site/进行安装。

也可以在http://www.eclipse.org/mat/downloads.php下载相应的操作系统的RCP客户端。

打开Eclipse，切换到DDMS透视图，同时确认Devices、Heap和logat视图已经打开。

将手机设备连接到电脑，并确保使用“USB调试“模式链接，

链接成功后在Devices视图中就会看到设备的序列号，和设备正在运行的部分进程。

选中想要分析的应用进程，在Devices视图上方的一行图标按钮中，同时选中“Update Heap”和“Dump HPROF file”按钮。

弹出Getting Started向导对话框，选中Leak Suspects Report，点击Finish按钮。

Eclipse自动跳转到Memory Analysize透视图，并打开default_report窗口。

该窗口列出了，可能有问题的代码片段。点击Details可以查看相关的详情。

在Shortest Paths To the Accumulation Point的列表中，我们可以追溯到问题代码的类树的结构，并找到自己代码中的类。

在列表中，有两列Shallow Heap和Retained Heap。Shallow Heap指的是所有的实例的内存总和。Retained Heap指的是所有类实例被分配的内存总和，里面包括它们所有引用的对象。

在Accumulated Objects列表中，我们可以看见创建的大量的对象。

在Accumulated Objects by Class列表中，我们能看见创建大量对象相关的类。

点击Histogrm按钮，显示了Histogrm视图，它显示了一个可以排序的类实例的列表。并可以根据自己的意愿，修改排序。

右击某一行，选择ListObjects>with incoming references，它会生成一个heap上的所有该对象数组的列表，我们可以按照Shallow Heap的使用情况来排序。

选择一个较大的对象，右击，选择Path to GCRoot->exclude weak/soft reference。

被JVM持有的对象，如当前运行的线程对象，被systemclass loader加载的对象称为GC Roots。从一个对象到GC Roots的引用链被称为Path to GC Roots，

通过分析Path to GC Root可以找出Java的内存泄露问题，当程序不在访问该对象时，仍然存在到该对象的引用路径。

MAT不会明确的告诉我们这就是内存泄露，因为它也不知道这个东西是不是程序需要的，只有程序员知道。

点击Domanitor_tree按钮，弹出新的窗口，列出了对中最大的对象，第二层级节点标识当被第一层级的节点所引用到的对象，当第一层级的节点被回收时，这些对象也将会回收。