这是一篇阅读MAT helper的笔记。Heap dump是java进程在特定时间的一个内存快照。通常在触发heap dump之前会进行一次full gc，这样dump出来的内容就包含的是被gc后的对象。
dump文件包含的内容：
1，全部的对象：类，域，原生值和引用；
2，全部的类：classloader，类名，超类，静态域；
3，GC root：被JVM定义的可触达的对象；
4，线程栈和本地变量：线程的call stack，本地对象每帧的信息。
dump文件不包含内存的分配信息，因此无法查询谁创建了哪个对象这样的信息。
Shallow heap是一个对象占用的内存空间，一个对象需要32或者64bits。
Retained set of X是X在被jvm gc回收后被remove的一组object。
Retained heap of X是在retained set of X中的所有对象的shallow heap size的和。换句话说就是保持X活着需要的内存空间。
通俗的讲，shallow heap是一个对象在内存中的实际空间，而retained heap是一个对象被gc回收后内存释放出来的空间。
这张图可以看懂什么是leading set什么是retained set。
Dominator tree：定义一个对象x dominate 对象y，当每一条从root开始到y的路径都经过x。说白了就是只要有y对象的存活，那么一定会有一个x对象。Dominator tree就是将对象引用图转换成的树形结构。帮助发现在对象间保持alive的依赖，同时也能识别出retained内存的最大的chunk。 Immediate dominator x of y是离y最近的dominator。
Dominator tree有几个属性：
1，对象x的子树包含的对象（x dominate的对象集），代表了x的retained set；
2，如果x是y的immediate dominator，那么x的immediate dominator同样dominate y，以此类推；
3，dominate tree中的边不代表对象引用图里对应的边，并非严格的直接的对象引用。
这张图反应了一个对象引用图转换成dominator tree的示例。
Gc root：一个gc根就是一个对象，这个对象从堆外可以访问读取。以下一些方法可以使一个对象成为gc根。
1，System class：被Bootstrap或者system类加载器加载的类，比如rt.jar里的java.util.*；
2，JNI local：native代码里的local变量，比如用户定义的JNI代码和JVM的内部代码；
3，JNI global：native代码里的global变量；
4，Thread block：当前活跃的线程block中引用的对象；
5，Thread：已经启动并且没有stop的线程；
6，busy monitor：被调用了wait()或者notify()或者被synchronized同步的对象，如果是synchronized方法，那么静态方法指的类，非静态方法指的是对象；
7，java local：local变量，比如方法的入参和方法内创建的变量；
8，native stack：native代码里的出入参数，比如file/net/IO方法以及反射的参数；
9，finalizable：在一个队列里等待它的finalizer 运行的对象；
10，unfinalized：一个有finalize方法的对象，还没有被finalize，同时也没有进入finalizer队列等待finalize；
11，unreachable：不会被触碰到的对象，在MAT里被标记为root用来retain object，否则是不会在分析中出现的；
12，java stack frame：java栈帧包含了本地变量，当dump被解析时且在preferences里设置过把栈帧当做对象，这时才会产生；
13，unknown：位置的root类型。
接下来是一些获取dump的方法：
1，在oom时dump：JVM参数：-XX:+HeapDumpOnOutOfMemoryError
2，交互式环境下dump：
1）JVM参数：-XX:+HeapDumpOnCtrlBreak
2）用外部tools：jmap -dump:format=b,file=
3）用外部tools：jconsole
4）用外部工具：MAT
5）kill -3
6）jstack -l >
一些排查方法：
1，通过top consumers查找大对象，可以按照class、classloader和package进行group by；
2，通过immediate dominator找到责任对象，对于快速定位一组对象的持有者非常有用，这个操作直接解决了“谁让这些对象alive”的问题，而不是“谁有这些对象的引用”的问题，更直接高效；
3，运行classloader分析，这个重要性体现在亮点：第一，应用使用不同的classloader加载类，第二，不同 classloader加载的类存储在不同的永久代，这理论上也是可以被回收的。当有一个类被不同的classloader加载时，这时要根据各自 loader下的instance数量判断哪个loader更重要，从而要把另一个回收掉；
4，分析线程，本身heap dump里包含了thread信息，可以通过MAT来查看threads 的overview和detail，detail中有线程的堆内存信息，也有线程栈，同时还包含了操作系统本地栈。假设不做heap dump，我们检查到系统有问题，如何通过线程的角度来排查呢？首先top -H -p 以线程的模式查看java应用的运行情况，找到占用cpu或者内存大的线程，记录线程id，然后printf %x 转为16进制，再jstack -l > thread.log把java进程的thread dump出来，从里面找到tid，分析是哪个线程占用了系统资源。
5，分析java容器类，因为java的容器类是最常用来存储对象的，所以理论上发生内存泄露的风险也最高。可以从几个角度来 看：1）array填充率查询（填充率fill ratio是数组中非空元素的比例），打印非原生类型数组的填充率频率分布，从而排查系统中array的利用率；2）数组按照size分组查询，打印一个 按size分组的直方图；3）collection的填充率查询，ArrayList/HashMap/Hashtable/Properties /Vector/WeakHashMap/ConcurrentHashMap$Segment；4）collection按照size分组直方图；5） 查看一个list里的所有对象；6）查看hashmap里的所有对象；7）查看hashset里的对象；8）检查map的碰撞率；9）检查所有只有一个常 量的array。
6，分析Finalizer，1）查询finalizer正在处理的对象；2）查询finalizer准备处理的对象；3）直接查看finalizer线程；4）查看finalizer线程的thread local对象。