这是一篇阅读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=<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,分析是哪个线程占用了系统资源。
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对象。