需要注意mat版本。 请使用内存分析器-1.4.0. 20140604-win32.win32.x86版本。 其他版本似乎取决于较高版本的jdk
Eclipsememoryanalyzertool(mat )是一种功能强大的基于eclipse的内存分析工具，有助于发现内存泄漏并减少内存消耗。
工作中可能会出现内存溢出、内存泄漏等问题，同时CPU的利用率也可能会提高。 由于GC垃圾回收频繁，在这种情况下，需要分析问题的原因。 虽然MAT是一个比较容易使用的工具，但刚开始使用时，我们对它所提供的功能还不太了解，所以我们在此总结了我们认为对我们个人有用的MAT相关概念，其他功能还没有使用，或者我们还不知道如何使用，我们将在后面补充一下。
以下是这篇文章的目录大纲。
视图功能
如有不正当行为，敬请谅解。 欢迎批评指正、讨论。
请尊重作者的劳动成果，注明原文链接：
视图功能
1、概览
在FileOpen Heap Dump .中打开dump文件时，将首先显示Overview摘要界面，其中包含Heap Dump的摘要，并提供有助于分析Heap Dump的视图和报告入口。 这些视图，报告稍后说明。
当鼠标悬停在饼图上时，对象的详细信息将显示在左侧，就像左上角的Inspector一样。 例如，对象的hashcode、类名、包名、Class类对象、父类、类加载器、shallow size、retained size和GC root类型。 左下方显示了对象的一些属性信息、类级别信息。
2、Histogram视图
您可以使用以下方法打开Histogram条形图：
(1)点击Overview页面的Actions区域内的“histogram view”链接
)2)点击工具栏上的“histogram按钮”
Histogram视图：
此视图显示每个类的实例存在的数量，使用的[Shallow内存]和[Retained内存]的大小(在类的维中)，并且可以对它们进行排序和显示。
在Histogram视图中，您可以看到哪个Class类的对象实例数较多，内存消耗较多。 Shallow Heap和Retained Heap的区别将在后面的概念介绍中说明。
但是，在大多数情况下，在Histogram视图中实例对象数较多的类是构成String、String、byte[]的char[]等基本类型，因此，仅这些类具体会导致内存泄漏可以使用List objects和mergeshoots如果Histogram视图中显示的大量实例对象不是基本类型，而是疑似类(如项目代码中的bean类型)，则需要注意。
3、管理员树视图
您可以使用以下方法打开管理员树视图：
(1)点击Overview页面的Actions区域内的“dominator tree view”链接
)2)单击工具栏上的" Dominator Tree "按钮，打开整个堆的控制树视图
管理员树视图：
此视图将当前在堆中使用Retained Heap最多的对象以及依赖这些对象生存的对象的树结构显示为实例对象的维
显示了实例对象名称、Shallow Heap大小、Retained Heap大小以及当前对象占整个堆的Retained Heap的百分比
单击Dominator Tree实例对象左侧的，将显示下一级" next level "；如果清除了引用当前实例对象的所有引用，则下一级将列出该对象
这也明确了“统治”的含义。 回收父节点时，也会回收子节点。 也就是说，子节点因父节点的存在而生存
Dominator Tree控制树可以很容易地找到占用Retained Heap内存最多的几个对象，指示哪些对象为哪个对象而存在，以及随后的dominator treap控制树
4、分组功能
要使用分组功能，请在Histogram和Domiantor Tree视图中单击工具栏上的Group result by .
也可以在其他组中显示。 默认值为nogrouping(objects )，按对象维分组。
>例如在Histogram视图 或 Dominator Tree视图，选择Group by package，可以更好地查看具体是哪个包里的类占用内存大，也很容易定位到自己的应用程序5、Thread Overview
Thread视图的入口，在工具栏上：
Thread Overview：
在Thread Overview视图可以看到：线程对象/线程栈信息、线程名、Shallow Heap、Retained Heap、类加载器、是否Daemon线程等信息
在分析内存Dump的MAT中还可以看到线程栈信息，这本身就是一个强大的功能，类似于jstack命令的效果
而且还能结合内存Dump分析，看到线程栈帧中的本地变量，在左下方的对象属性区域还能看到本地变量的属性，真的很方便
在上面代码的Heap Dump分析中，可以看到线程调用栈的信息，以及main线程的 本地变量TestThreadOverview 和 字符串local_str 的信息
上图中第一个框起来的部分是 new TestThreadOverview()对象(代码第6行)，TestThreadOverview对象有两个属性str1、str2
第二个框起来的部分是main方法中的字符串变量local_str(代码第8行)
结合左侧的对象属性区域，可以更方便的看清线程中对象的具体情况
6、List objects
在 Histogram 或 Dominator Tree视图，想要看某个条目(对象/类)的引用关系图，可以使用 List objects 功能
(1)选择一个条目后，点击工具栏的 Query Browser > List objects，选择 with outgoing references 或 with incoming references
(2)直接在某个条目上点击右键，也可以选择到List object
List objects --> with outgoing references
：查看当前对象持有的外部对象引用(在对象关系图中为从当前对象指向外的箭头)
List objects --> with incoming references
：查看当前对象被哪些外部对象所引用(在对象关系图中为指向当前对象的箭头)
例如上面Thread Overview的例子代码中，查看main方法中第6行中的
outgoing references查询结果为：
可以看到TestThreadOverview对象存在3个引用，第一个是TestThreadOverview的Class类对象，因为所有Java类都继承自java.lang.Object，所以都有class对象的引用，后两个是成员变量str1、str2
即列出了当前main方法中的局部变量TestThreadOverview所持有的所有外部对象引用
incoming references查询结果为：
可以看到TestThreadOverview是main线程的一个本地局部变量，main线程本身还是一个GC root，而main线程在某个ThreadGroup中
7、Paths to GC Roots(从对象到GC Roots的路径) & Merge Shortest Paths to GC roots(从GC Roots到对象的共同路径)
Paths to GC Roots
：从当前对象到GC roots的路径，这个路径解释了为什么当前对象还能存活，对分析内存泄露很有帮助，这个查询只能针对单个对象使用
Merge Shortest Paths to GC roots
：从GC roots到一个或一组对象的公共路径
Path to GC roots 和 Merge shortest Paths to GC roots 这两个查询都有很多选项，如：
意思是在查询到GC root的路径时，是包含所有引用，还是排除一些类型的引用(如软引用、弱引用、虚引用)，从GC角度说，一个对象无法被GC，一定是因为有强引用存在，其它引用类型在GC需要的情况下都是可以被GC掉的，所以可以使用 exclude all phantom/weak/soft etc. references 只查看GC路径上的强引用
Path to GC roots 和 Merge shortest Paths to GC roots 的入口和 List objects一样，可以从工具栏的 Query Browser 进入，或者在条目上直接点击右键进入
需要注意的是，Paths to GC roots是针对单个对象的，故在Histogram视图无法使用，因为Histogram视图是针对类的，只能使用Merge shortest Paths to GC roots查询
8、Leak Suspects Report(内存泄露报告)
使用MAT打开一个Dump文件时，会弹出向导窗口，保持默认选项，点Finish，就会导向 Leak Suspects内存泄露报告页面
如果打开Dump时跳过了的话，也可以从其它入口进入，如
(1)工具栏上的 Run Expect System Test > Leak Suspects
(2)Overview页面的Reports部分
Leak Suspects 是MAT帮我们分析的可能有内存泄露嫌疑的地方，可以体现出哪些对象被保持在内存中，以及为什么它们没有被垃圾回收
MAT提供了一个很贴心的功能，将报告的内容压缩打包到一个zip文件，并放在原始堆转储文件的目录下，一般命名为“xxx_Leak_Suspects.zip”，xxx是dump文件的名字，如果需要和同事一起分析这个内存问题的话，只需要把这个小小的zip包发给他就可以了，不需要把整个堆文件发给他。并且整个报告是一个HTML格式的文件，用浏览器就可以轻松打开内存泄露的概念：1、内存泄露的这些对象是从GC root可达的，从GC root存在通路可以与其相连
2、这些对象是无用的，即程序以后不会再使用这些对象
至于怎么定义程序不会再使用的对象，那就要看具体的程序逻辑了，说白了内存泄露就是该回收的内存没有被回收
下面用一个例子分析如何使用Leak Suspects Report内存泄露报告
上面的代码中创建了很多OOMBean，并放入了Map和数组中，由于是强引用，在主线程运行结束前，GC自然不会回收，一直到内存溢出。
在运行前设置一些VM参数：-Xms2m -Xmx2m -XX:+HeapDumpOnOutOfMemoryError
以便程序可以OutOfMemory，并在发生内存溢出时自动生成内存快照
程序运行一会儿后，控制台打印
java_pid10160.hprof 就是内存dump，可以在OOMHeapTest类所在工程的根目录下找到
Leak Suspects：
MAT工具分析了heap dump后在界面上非常直观的展示了一个饼图，该图深色区域被怀疑有内存泄漏，可以发现整个heap才6.8M内存，深色区域就占了92.11%。接下来是一个简短的描述，告诉我们main线程占用了大量内存，并且明确指出system class loader加载的“java.lang.Thread”实例有内存聚集，并建议用关键字“java.lang.Thread”进行检查。在下面还有一个“Details”链接，可以查看明细信息。
Details明细：
Details的最开始是Description描述，和前一个页面对内存泄露嫌疑点的描述一致，下面有一些与怀疑的内存泄露点关联的查询结果展示，是分析报告中认为可能会存在问题，协助我们深入分析问题根源的，具体如下：
(1)Shortest Paths To the Accumulation Point
实际上展开的视图是当前对象“java.lang.Thread @ 0xffc59ab0 main”的 Path to GC roots，即到GC roots的路径，点击标题右侧的按钮可以在另一窗口打开
这个视图的作用是可以分析是由于和哪个GC root相连导致当前Retained Heap占用相当大的对象无法被回收
由于是分析内存泄露的报告，找到导致当前对象无法被回收的GC roots，分析这些GC roots是否合理，是有必要的
但本例中由于main线程本身就是GC root，故只有一条数据
(2)Accumulated Objects in Dominator Tree
这个视图以对象的维度展示了以当前对象“java.lang.Thread @ 0xffc59ab0 main”为根的 Dominator Tree支配树，可以方便的看出受当前对象“支配”的对象中哪个占用Retained Heap比较大
观察Accumulated Objects部分，java.lang.Object[1000000]实例 和 java.util.HashMap 和 的Retained Heap(Size)最大，Retained Heap代表从该类实例沿着reference chain往下所能收集到的其他类实例的Shallow Heap(Size)总和，所以明显类实例都聚集在HashMap和Object数组中了
在Accumulated Objects视图中，Retained heap占用最多的是HashMap和object数组，为啥它们会占用这么大的heap呢？这个时候需要分析HashMap和object数组中存放了一些什么对象？接着往下看 Accumulated Objects by Class in Dominator Tree
(3)Accumulated Objects by Class in Dominator Tree
这个视图实际上是展示了以当前对象“java.lang.Thread @ 0xffc59ab0 main”为根的Dominator Tree支配树，并以Class类分组
可以看到 OOMBean类 的实例最多，有11786个，程序中确实是在循环创建OOMBean实例，并放入object数据和HashMap中
这样就可以确定Heap占用大时由于OOMBean类的实例创建的太多的原因了
(4)Thread Detail
Detail明细的最后由于当前怀疑泄露点为main Thread线程对象，故展示了线程明细信息，调用栈信息，对分析内存溢出的发生位置很有帮忙