内存OOM排查神器分析工具之mat(MemoryAnalyzer)使用手册

介绍


大家都知道,在存储用户输入的密码时候,会使用一些hash算法对密码进行加工,比如sha-1、bcrypt。这些信息同样不允许在日志输出里出现,必须做脱敏处理。但是对于一个拥有系统权限的攻击者来说,这些防护依然是不够的。攻击者可能会直接从内存中获取明文数据,尤其对于Java来说,由于提供了jmap一类非常方便的工具,可以把整个堆内存的数据dump下来。比如,“我的世界”一类使用Java开发的游戏,会比其他语言的游戏更加容易破解一些,所以我们在JVM中,如果把密码存储为char数组,安全性会稍微高一些。

这是一把双刃剑,在保证安全的前提下,我们也可以借助一些外部的分析工具,帮助我们方便的找到问题根本。

可以有两种方式来获取内存的快照。我们前面提到,通过配置一些参数,可以在发生OOM的时候,被动dump一份堆栈信息,这是一种。另一种,就是通过jmap主动去获取内存的快照。

jmap命令在Java9之后,使用jhsdb命令替代,它们在用法上,区别不大。注意,这些命令本身会占用操作系统的资源,在某些情况下会造成服务响应缓慢,所以不要频繁执行。

jmap -dump:format=b,file=heap.bin 37340
jhsdb jmap  --binaryheap --pid  37340

1、工具介绍


专业的事情要有专业的工具来做,今天给大家介绍的是一款专业的开源分析工具,叫做MAT。

https://www.eclipse.org/mat/MAT工具是基于eclipse平台开发的,本身是一个Java程序,所以如果你的堆快照比较大的话,就需要一台内存比较大的分析机器,并给MAT本身加大初始内存,这个可以修改安装目录中的MemoryAnalyzer.ini文件。

可以看一下MAT工具的截图,主要功能都体现在工具栏上。其中,默认的启动界面,展示了占用内存最高的一些对象,并有一些常用的快捷方式。通常,发生内存泄漏的对象,会在快照中占用比较大的比重,分析这些比较大的对象,是我们切入问题的第一步。
在这里插入图片描述
点击对象,可以浏览对象的引用关系。这是一个非常有用的功能。

  • outgoing references 对象的引出。
  • incoming references 对象的引入。
  • path to GC Roots 这是快速分析的一个常用功能,显示和GC Roots之间的路径。
    在这里插入图片描述
    另外一个比较重要的概念,就是浅堆(Shallow Heap)和深堆(Retained Heap),在MAT上经常看到这两个数值。
    在这里插入图片描述
    浅堆代表了对象本身的内存占用。包括对象自身的内存占用,以及“为了引用”其他对象所占用的内存。

深堆是一个统计结果,会循环计算引用的具体对象所占用的内存。但是深堆和“对象大小”有一点不同,深堆指的是一个对象被垃圾回收后,能够释放的内存大小,这些被释放的对象集合,叫做保留集(Retained Set)。
在这里插入图片描述
如上图,A对象浅堆大小1KB,B对象2KB,C对象100KB。A对象同时引用了B对象和C对象,但由于C对象也被D引用,所以A对象的深堆大小为3KB(1KB+2KB)。

A对象大小(1KB+2KB+100KB)> A对象深堆 > A对象浅堆。

2、内存泄漏检测


如果问题特别突出,可以通过Find Leaks菜单快速找出问题。
在这里插入图片描述
如图,展示了名称叫做huge-thread的线程,持有了超过96%的对象,数据被一个HashMap所持有。

在这里插入图片描述
对于特别明显的内存泄漏,在这里能够帮助我们迅速定位,但通常内存泄漏问题会比较隐蔽,我们需要更加复杂的分析。

3、支配树视图


支配树视图对数据进行了归类,体现了对象之间的依赖关系。如图,我们通常会根据“深堆”进行倒序排序,可以很容易的看到占用内存比较高的几个对象。点击前面的箭头,即可一层层展开支配关系。

图中显示的是其中的1MB数据,从左侧的inspector视图,可以看到这1MB的byte数组具体内容。
在这里插入图片描述
从支配树视图同样能够找到我们创建的两个循环依赖。但它们并没有显示这个过程。

在这里插入图片描述
支配树视图的概念有一点点复杂,我们只需要了解这个概念即可。

在这里插入图片描述
如上图,左边是引用关系,右边是支配树视图。可以看到A、B、C被当作是“虚拟”的根。支配关系是可传递的,因为C支配E,E支配G,所以C也支配G。

另外,到对象C的路径中,可以经过A,也可以经过B,因此对象C的直接支配者也是根对象。同理,对象E是H的支配者。

我们再来看比较特殊的D和F。对象F与对象D相互引用,因为到对象F的所有路径必然经过对象D,因此,对象D是对象F的直接支配者。

可以看到支配树视图并不一定总是能看到对象的真实应用关系,但对我们分析问题的影响并不是很大。

这个视图是非常好用的,甚至可以根据package进行归类,对目标类的查找是非常快捷的。
在这里插入图片描述
编译下面这段代码,可以展开视图,实际观测一下支配树,这和我们上面介绍的是一致的。

public class DorminatorTreeDemo {
    static class A {
        C c;

        byte[] data = new byte[1024 * 1024 * 2];
    }

    static class B {
        C c;
        byte[] data = new byte[1024 * 1024 * 3];
    }

    static class C {
        D d;
        E e;
        byte[] data = new byte[1024 * 1024 * 5];
    }

    static class D {
        F f;
        byte[] data = new byte[1024 * 1024 * 7];
    }

    static class E {
        G g;
        byte[] data = new byte[1024 * 1024 * 11];
    }

    static class F {
        D d;
        H h;
        byte[] data = new byte[1024 * 1024 * 13];
    }

    static class G {
        H h;
        byte[] data = new byte[1024 * 1024 * 17];
    }

    static class H {
        byte[] data = new byte[1024 * 1024 * 19];
    }

    A makeRef(A a, B b) {
        C c = new C();
        D d = new D();
        E e = new E();
        F f = new F();
        G g = new G();
        H h = new H();
        a.c = c;
        b.c = c;
        c.e = e;
        c.d = d;
        d.f = f;
        e.g = g;
        f.d = d;
        f.h = h;
        g.h = h;
        return a;
    }

    static A a = new A();
    static B b = new B();

    public static void main(String[] args) throws Exception {

        new DorminatorTreeDemo().makeRef(a, b);

        Thread.sleep(Integer.MAX_VALUE);
    }
}
在这里插入图片描述

4、线程视图


想要看具体的引用关系,可以通过线程视图。我们在第5小节,就了解到线程其实是可以作为GC Roots的。如图展示了线程内对象的引用关系,以及方法调用关系,相对比jstack获取的栈dump,我们能够更加清晰的看到内存中具体的数据。

如下图,我们找到了huge-thread,依次展开找到holder对象,可以看到循环依赖已经陷入了无限循环的状态。这在查看一些Java对象的时候,经常发生,不要感到奇怪。
在这里插入图片描述

5、柱状图视图


我们返回头来再看一下柱状图视图,可以看到除了对象的大小,还有类的实例个数。结合MAT提供的不同显示方式,往往能够直接定位问题。也可以通过正则可以过滤一些信息,我们在这里输入MAT,过滤猜测的、可能出现问题的类。可以看到我们创建的这些自定义对象,不多不少正好一百个。
在这里插入图片描述
右键点击类,然后选择incoming,这会列出所有的引用关系。

在这里插入图片描述
再次选择某个引用关系,然后选择菜单“Path To GC Roots”,即可显示到GC Roots的全路径。通常在排查内存泄漏的时候,会选择排除虚弱软等引用。

在这里插入图片描述
在这里插入图片描述
使用这种方式,即可在引用之间进行跳转,方便的找到所需要的信息。

在这里插入图片描述

再给大家介绍一个比较高级的功能。

我们对于堆的快照,其实是一个“瞬时态”,有时候仅仅分析这个瞬时状态,并不一定能确定问题,这就需要对两个或者多个快照进行对比,来确定一个增长趋势。

在这里插入图片描述
可以将代码中的100改成10或其他数字,再次dump一份快照进行比较。如图,通过分析某类对象的增长,即可辅助问题定位。

6、高级功能-OQL


MAT支持一种类似于SQL的查询语言OQL(Object Query Language),这个查询语言VisualVM工具也支持。
在这里插入图片描述
以下是几个例子,大家可以实际实践一下。

查询A4MAT对象。

SELECT * FROM  Objects4MAT$A4MAT 

正则查询MAT结尾的对象。

SELECT * FROM ".*MAT" 

查询String类的char数组。

SELECT OBJECTS s.value FROM java.lang.String s 
SELECT OBJECTS mat.b4MAT FROM  Objects4MAT$A4MAT mat

根据内存地址查找对象。

select * from 0x55a034c8 

使用INSTANCEOF关键字,查找所有子类。

SELECT * FROM INSTANCEOF java.util.AbstractCollection 

查询长度大于1000的byte数组。

SELECT * FROM byte[] s WHERE s.@length>1000

查询包含java字样的所有字符串。

SELECT * FROM java.lang.String s WHERE toString(s) LIKE ".*java.*" 

查找所有深堆大小大于1万的对象。

SELECT * FROM INSTANCEOF java.lang.Object o WHERE o.@retainedHeapSize>10000

如果你忘记这些属性的名称的话,MAT是可以自动补全的。
在这里插入图片描述
OQL有比较多的语法和用法,深入可以参考

http://tech.novosoft-us.com/products/oql_book.htm
一般,我们使用上面这些简单的查询语句就够用了。

OQL还有一个好处,就是可以分享。如果你和同事同时在分析一个大堆,你不必告诉他先点哪一步,再点哪一步,共享给他一个OQL语句就可以了。

如下图,MAT贴心的提供了复制OQL的功能,但是用在其他快照上,不会起作用,因为它复制的是如下的内容。
在这里插入图片描述

7、总结


我们把问题设定为内存泄漏,但其实OOM或者频繁GC不一定就是内存泄漏,它也可能是由于某次或者某批请求频繁创建了大量对象,所以一些严重的、频繁的GC问题也能在这里找到原因。有些情况下,占用内存最多的对象,并不一定是引起内存泄漏问题的元凶,但我们也有一个比较通用的分析过程。

并不是所有的堆都值得分析的。我们分析在做这个耗时的分析之前,需要有个依据。比如,经过初步调优之后,GC的停顿时间还是较长,我们需要找到频繁GC的原因;再比如,我们发现了内存泄漏,需要找到是谁在搞鬼。

首先,我们高度关注快照载入后的初始分析。占用内存高的topN对象,大概率是问题产生者。

如果不能通过大对象发现问题,就需要对快照进行深入分析。使用柱状图和支配树视图,配合引入引出和各种排序,能够对内存的使用进行整体的摸底。由于我们能够看到内存中的具体数据,排查一些异常数据就容易的多。

可以在程序运行的不同时间点,获取多份内存快照,对比之后问题会更加容易发现。我们还是用一个例子来看。有一个应用,使用了Kafka消息队列,开了一般大小的消费缓冲区,Kafka会复用这个缓冲区,按理说不应该有内存问题,但是应用却频繁发生GC。通过对比请求高峰和低峰期间的内存快照,我们发现有工程师把消费数据放入了另外一个 “内存队列”,写了一些画蛇添足的代码,结果在业务高峰期一股脑把数据加载到了内存中。

上面这些问题通过分析业务代码,也不难发现其关联性。问题如果非常隐蔽,就需要使用OQL等语言,对问题一一排查、确认。

可以看到,MAT工具的上手是有一定门槛的,除了其操作模式,还需要对我们前面介绍的理论知识有深入的理解。比如GC Roots,各种引用级别等。

在很多场景,MAT并不仅仅用于内存泄漏的排查。由于我们能够看到内存上的具体数据,在排查一些难度非常高的bug时,MAT也有用武之地。比如,因为某些脏数据,引起了程序的执行异常。这个时候,想要找到它们,不要忘了MAT这个老朋友。

版权声明:本文为作者原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。

原创文章,作者:老C,如若转载,请注明出处:https://www.code404.icu/1225.html

发表评论

登录后才能评论