Java内存分析利器MAT使用详解

这是一篇阅读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回收后内存释放出来的空间。

Java内存分析利器MAT使用详解

这张图可以看懂什么是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中的边不代表对象引用图里对应的边,并非严格的直接的对象引用。

Java内存分析利器MAT使用详解

这张图反应了一个对象引用图转换成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=<filename.hprof> <pid>

3)用外部tools:jconsole

4)用外部工具:MAT

5)kill -3 <pid>

6)jstack -l <pid> > <dumpfile>

一些排查方法:

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 <pid>以线程的模式查看java应用的运行情况,找到占用cpu或者内存大的线程,记录线程id,然后printf %x <tid>转为16进制,再jstack -l <pid> > thread.log把java进程的thread dump出来,从里面找到tid,分析是哪个线程占用了系统资源。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/3a9ecf57aab4c9e4bf4ee9eda1132999.html