Log4J日志打印引发的OOM问题排查

Log4J日志打印引发的OOM问题排查

上周，充当回消防队员去救火，一个老的CRM系统，生产上一天出现了CPU占用高，两次OOM问题。从时间上看，CPU占用高的报警也是因为JVM为了自救的疯狂GC导致的。

查看Dump文件

OOM提供了堆Dump以及线程栈Dump。由于是内网，无法截图，也不方便拍照。在此就引用一篇来自老东家的，极度相似的博客：https://rdc.hundsun.com/portal/article/884.html

栈Dump

从栈Dump线程中，可以看到大部分线程都在com.lmax.disruptor.RingBuffer#next()的UNSAFE.park()方法中。其堆栈的入口全是log4j的append方法中。

堆Dump

用mat打开was的Dump phd文件（工具不一定，但是was的我还是第一次遇到这个格式）

堆Dump中可以看到4G的内存，3.8G均为RingBuffer占用，毫无疑问，这个类所占肯定过多，而且还没法回收。

排查问题

JVM 内存溢出无非两种大情况，内存泄露，或者内存不足。情况一不管分配多大内存都不会足够，情况二，需要考虑加大内存，或者减少、限制内存的使用。

对于log4j这种成熟的组件，我一般不会怀疑其是内存泄露。当然，我还是找到那个工程使用的版本，下载源码进行查看：

        <!-- https://mvnrepository.com/artifact/com.lmax/disruptor -->
        <dependency>
            <groupId>com.lmax</groupId>
            <artifactId>disruptor</artifactId>
            <version>3.3.6</version