使用 Eclipse Memory Analyzer 分析内存溢出.docxVIP

使用 Eclipse Memory Analyzer 分析内存溢出 2021-11-20 最近，线上生产系统突然频繁的 JVM 内存报警！但本系统近期内并没有上线改动！ 为了能查清内存报警的缘由，使用 Eclipse Memory Analyzer tool（MAT）对 JVM Dump 文件进行了分析！ 1. 生成 dump 文件 用 jmap 生产 dump 文件 1 jmap?-dump:format=b,file=HeapDump.bin? 2. MAT 安装与引见 下载地址：/mat/downloads.php 通过 MAT 打开 dump 出来的内存文件，打开后如下图： Histogram 可以列出内存中的对象，对象的个数以及大小。 Histogram 如下图： Objects：类的对象的数量。 Shallow size：就是对象本身占用内存的大小，不包含对其他对象的引用，也就是对象头加成员变量（不是成员变量的值）的总和。 Retained size：是该对象本人的 shallow size，加上从该对象能直接或间接访问到对象的 shallow size 之和。换句话说，retained size 是该对象被 GC 之后所能回收到内存的总和。 我们发觉 ConcurrentHashMap 类的对象占用了很多空间。 Leak Suspects 如下图： 从那个饼图，该图深色区域被怀疑有内存泄漏，可以发觉整个 heap 2G 内存，深色区域就占了 98%。后面的描述，说明内存被一个实例占用了大量内存，并指出 system class loader 加载的java.util.concurrent.concurrentHashMap$Segmen[]实例的内存中聚集（消耗空间），并建议用关键字java.util.concurrent.concurrentHashMap$Segmen[]进行检查。所以，MAT 通过简约的报告就说明白问题所在。 Dominator Tree 如下图： 我们逐层打开 concurrentHashMap 的内存结构，发觉 Key 格外多，并且最底层的 String 长度很大！ 侥幸的是该系统的下游也是我们担任的系统，猜想 concurrentHashMap 应当是 RPC 调用前往回值待处理的内存存储，正常情况这个 String 的长度不很大。认真查看， String 里包含了多了很多具体的特别描述信息，之前是没有的。 排查下游系统代码，发觉在前往特别时，与之前特别抛出有所不同： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 try?{ }?catch(Exception?e)?{ ????throw?e; } ? ... ? try?{ }?catch(Exception?e)?{ ????throw?new?Exception(xxxx,?e); } ? //?前往伪代码 response(e.getMessage); 就是有这些许的不同，我们看下源代码： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ????public?Throwable(String?message,?Throwable?cause)?{ ????????fillInStackTrace(); ????????detailMessage?=?message; ????????this.cause?=?cause; ????} ? ????public?Throwable(Throwable?cause)?{ ????????fillInStackTrace(); ????????detailMessage?=?(cause==null???null?:?cause.toString()); ????????this.cause?=?cause; ????} ? ????public?String?getMessage()?{ ????????return?detailMessage; ????} 当没有 message，message = cause.toString()，所以就形成了前往大量不必要的特别信息，从而影响了上游系统！