/**
*
*/
package simple.test;
import java.util.ArrayList;
import java.util.List;
/**
* @author: 作者： chengaofeng
* @date: 创建时间：2018-09-11 16:50:59
* @Description: TODO
* @version V1.0
*/
public class MatSimple {
public static void main(String[] args) {
PersonRepo pp = new PersonRepo();
pp.autoCreatePerson(10000000);
}
public static class PersonRepo {
private List<Person> repo = new ArrayList<>();
public void autoCreatePerson(long count) {
for (long l = 0; l < count; l++) {
repo.add(new Person(l));
}
}
}
public static class Person {
private long num;
/**
* @param num
*/
public Person(long num) {
this.num = num;
}
public long getNum() {
return this.num;
}
}
}
我们通过在eclipse中配置运行参数的形式获取对应的dump
[img]http://dl2.iteye.com/upload/attachment/0130/7122/43f72397-be22-377b-bbb3-07340cf3a777.png[/img]
执行run，很快在控制台中会出现异常以及生成dump文件的信息
[img]http://dl2.iteye.com/upload/attachment/0130/7124/f22214ce-69ad-33bf-b8f9-a0153f406279.png[/img]
2.利用MAT打开dump文件 File > Open Heap Dump…
默认情况会让选择一个报告模式，可以跳过，也可以选择任意一个选择finish，之后进入Overview界面
[img]http://dl2.iteye.com/upload/attachment/0130/7126/fb022f12-728b-3b9b-b48d-899a2e312c82.png[/img]
2.1 Overview
[img]http://dl2.iteye.com/upload/attachment/0130/7128/ea052da4-20cb-36e4-a61b-3623cd751fa7.png[/img]
在右侧的窗口的details分类下可找到dump的大小，类、对象、以及类加载器的个数。
接下来的饼图中列出了dump中的大对象，一般情况下当某一类对象占用的特别多时就是程序有内存泄漏的可能了。当鼠标滑过一个饼图中的一个分类时在右侧会显示详细信息，点击在弹出菜单中可进一步对这一类对象进行分析。
2.2 Histogram
通过工具栏中的Histogram按钮或者在Overview界面的action中选择Histogram可以打开Histogram界面。
[img]http://dl2.iteye.com/upload/attachment/0130/7136/81c1d33f-75ee-3899-b383-c02f93fa385f.png[/img]
通过Histogram可以看到每类对象的个数以及[url=http://fengyilin.iteye.com/blog/2430305]shallow size 和 retained size[/url] .
[img]http://dl2.iteye.com/upload/attachment/0130/7134/2446d384-2992-3c72-a179-cb42d22225cb.png[/img]
在这个页面，我们已经很明确看出来，现在dump中主要是存储了大量的simple.test.MatSimple$Person对象（1,215,488个,占用了快30M的内存）对于我们的测试应用来说已经能发现是对Person对象的处理有问题造成了内存泄漏。
在这个页面我们可以对任何有疑问的对象做进一步分析
[img]http://dl2.iteye.com/upload/attachment/0130/7138/0a5baa72-b3c2-33a7-9c44-052c931d2302.png[/img]
或者对对象分组排序等操作
[img]http://dl2.iteye.com/upload/attachment/0130/7140/ba0aeb67-97a5-32a3-b829-28349407bc7c.png[/img]
例如按package排序后很容易就能看出是哪个package中的类占用的内存比较多
[img]http://dl2.iteye.com/upload/attachment/0130/7142/c4819507-6865-3a3f-aaeb-6be08e7c24ca.png[/img]
2.3 Dominator Tree
通过工具栏中的[url=http://fengyilin.iteye.com/blog/2430305]Dominator Tree[/url]按钮或者在Overview界面的action中选择Dominator Tree可以打开Dominator Tree界面。
[img]http://dl2.iteye.com/upload/attachment/0130/7144/7c8b0430-c2c2-38ec-94c9-4c56614acd5b.png[/img]
Dominator Tree列出了dump中所有占用内存大的对象。Dominator Tree在分析dump中哪个对象保持其他对象存活方面非常强大。并且也可以用package、class loader来排序
[img]http://dl2.iteye.com/upload/attachment/0130/7146/892c94a2-967f-376f-8f8a-1c37994252fb.png[/img]
通过这个图，我们可以看到，在我们的例子中，主线程中保留了一个Person对象数组（list的底层实现是一个数组），里面保存了1,215,462个person对象，因为main tread无法被GC，造成大量的person对象无法被GC，即问题是出在主线程的一个存储Person对象的数组（list）中的。继而我们就可以发现代码问题了。
2.4 Path to GC Roots
GC Roots指的是那些被jvm保持存活状态的对象，通过分析一个对象到GC Roots的路径，可以更加清楚的看到是因为什么原因造成此对象在内存中一直存活的，即一个对象为什么没有被GC回收，在Dominator Tree界面选中人意我们想分析的对象，点击
[img]http://dl2.iteye.com/upload/attachment/0130/7148/ab2cc192-9212-3d04-bad3-9f17d3d5571c.png[/img]
[img]http://dl2.iteye.com/upload/attachment/0130/7150/d42f6c8e-e079-32fb-a9cd-7b9f7c61991d.png[/img]
可以看到我们的person对象是作为一个Object存储在了main Thread中的一个ArrayList中的。
2.5 The Leak Report
通过这个MAT会自动给我们一个最有可能引起内存问题的报告
[img]http://dl2.iteye.com/upload/attachment/0130/7152/408679de-2deb-399e-b1b8-df8d792e1c29.png[/img]
[img]http://dl2.iteye.com/upload/attachment/0130/7154/c325d6c7-b32a-3bb2-9174-2b3d4f1fba47.png[/img]
MAT给出的推断是main Thread中保持了一个Object[]变量，占用了大量的空间，点击details
[img]http://dl2.iteye.com/upload/attachment/0130/7156/6fad35b2-7c31-3924-b37d-3baa9bff98ec.png[/img]
在Dominator Tree堆积列表中，可以看出实际是存储了大量的Person对象。
2.6 Top Consumer
在Overview界面的actions中选择Top Consumer操作，可以列出dump中占用空间最大的对象，并用类和package分组，当我们分析的dump文件特别大时可以用这个操作先对大对象分析