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

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回收后内存释放出来的空间。这张图可以看懂什么是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:+HeapDumpOnOutOfMemoryError2，交互式环境下dump：1）JVM参数：-XX:+HeapDumpOnCtrlBreak2）用外部tools：jmap -dump:format=b,file= 3）用外部tools：jconsole4）用外部工具：MAT5）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）直接查