Java Web项目内存溢出问题排查

线上的一个spring boot项目每两个周会出现系统卡死，不能正常提供api服务，重启后恢复。经过查看日志发现大量的“java.lang.OutOfMemoryError: GC overhead limit exceeded”日志。这个异常的官方解释：

Exception in thread thread_name: java.lang.OutOfMemoryError: GC Overhead limit exceeded
Cause: The detail message “GC overhead limit exceeded” indicates that the garbage collector is running all the time and Java program is making very slow progress. After a garbage collection, if the Java process is spending more than approximately 98% of its time doing garbage collection and if it is recovering less than 2% of the heap and has been doing so far the last 5 (compile time constant) consecutive garbage collections, then a java.lang.OutOfMemoryError is thrown. This exception is typically thrown because the amount of live data barely fits into the Java heap having little free space for new allocations.
Action: Increase the heap size. The java.lang.OutOfMemoryError exception for GC Overhead limit exceeded can be turned off with the command line flag -XX:-UseGCOverheadLimit.

JVM用了98%的时间进行垃圾回收，而只得到2%可用的内存，频繁的进行内存回收。
结合现象，可以推测程序中某些实例的数量在缓慢的增长，但是一直不能被回收。虽然异常信息不是常见的“java.lang.OutOfMemoryError: Java heap space”，但是原因却是相同的。

那我就开始查找原因吧！先说一下笔者的思路：

1、从生成获取dump文件
2、使用jvisualvm.exe或Eclipse Memory Analyzer（MAT）进行内存分析

jvisualvm.exe（JDK自带的工具）
Eclipse Memory Analyzer（第三方的工具，可不依赖eclipse单独下载）

3、结合业务代码进行问题定位
4、提出修改方案

获取dump文件

可以直接在启动脚本中添加如下参数，在程序内存溢出时自动生成dump文件

-XX:+HeapDumpOnOutOfMemoryError   # 告诉jvm内存溢出时生成dump文件
-XX:HeapDumpPath=/tmp/dump   # 指定dump的路径

这个案发现场的第一手资料显然需要漫长等待过程，不如立即生成一份dump文件
先找到程序的pid（笔者这里时11008）然后使用下面的命令在当前目录执行：

/opt/jdk/bin/jmap -dump:format=b,file=20200508.dump 11008

内存分析

如果dump文件比较小，直接使用jdk安装路径/bin/jvisualvm.exe来分析，运行jvisualvm.exe，然后点击File - 装入

如果文件很大，比如笔者dump文件是2G左右，那就需要使用更强大的MAT工具。

下载地址Eclipse Memory Analyzer（MAT）

打开MAT之前，根据实际dump文件大小，调一下内存大小。

启动MAT，点击File - Open Heap Dump

这个工具很快就能加载完成，默认显示Overview界面

笔者常用的三个功能如上图标识，先借助Leak Suspects自动分析生成一个报告：

根据自动分析推测com.sun.jmx.mbeanserver.JmxMBeanServer这个对象占用了已消耗空间的91.93%，但这个类明显不是我们业务对象。

追根溯源，我们下一步就需要找出这个类和业务代码的关系。

使用Dominator Tree功能分析对象之间的支配关系。

在支配关系树种，我们依次展开Retained Heap值最大的那个支配者，最后发现是“org.apache.kafka.common.network.KafkaChannel”持有，最终也没追溯到我们自己写的业务代码。线索断了。。。。

Retained Heap：表示因为这个对象，导致所有引用这个对象而不能被回收的内存大小

虽然通过MAT我们没法定位到业务代码，但是也提供一个思路：

去业务代码中review与kafka相关的逻辑。

笔者发现业务代码中与kafka相关的逻辑，只有使用kafaka-client来连接kafka服务器，而当前这个应用，只是测试连通型，并且有个定时任务每小时会执行一次这个测试。会不会是这个测试代码写的有问题，导致对象没有被释放，导致的呢？
果然如此，笔者找到的代码片段如下：

public Integer testConnectionKafka(Long clusterId) {
	// .... 
	// ....
	// ....
	KafkaConsumer<Object, Object> kafkaConsumer = new KafkaConsumer<>(props);
	try {
	    kafkaConsumer.listTopics();
	} catch (Exception ex) {
	    throw new QdamException("KAFKA连接失败: " + ex.getMessage());
	}
	return SUCCESS;
}

这里每次调用testConnectionKafka()方法都会创建一个kafkaConsumer, 但是执行完这个方法，并没有关闭。笔者有理由怀疑可能和这里有关。修改方案也很简单，增加kafkaConsumer.close()即可。

} finally {
	kafkaConsumer.close();
}

修改后上线观察…