目录

前言

项目运行过程中，我们可能会遇到Java内存溢出Out Of Memory。此时我们可以借助内存分析工具MAT(Memory Analyzer Tool)，来定位是哪里出现了问题。

一、MAT（Memory Analyzer Tool）

下载地址：Eclipse Memory Analyzer Open Source Project | The Eclipse Foundation

注意：JDK-8建议使用11版本，否则会提示版本不兼容

二、软件初识

解压后目录内有个MemoryAnalyzer.ini文件，该文件里面有个-Xmx参数。该参数表示最大内存占用量，默认为1024m。
建议修改为小于本机内存大小，大于要分析的dump文件大小

-startup
plugins/org.eclipse.equinox.launcher_1.5.0.v20180512-1130.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.700.v20180518-1200
-vmargs
### -Xmx1024my原本默认为1024m，此处我修改为4096m
-Xmx4096m

三、捕获dump文件

        首先在程序中模拟出一段内存溢出的逻辑：

    @RequestMapping("/testOutOfMemory")
    @ResponseBody
    public void testOutOfMemory() throws Exception {
        String name = "Aikes";
        for (int i = 0; i < 10000000; i++) {
            name += name;
        }
        System.out.println(name);
    }

        然后启动项目，开始准备捕获dump文件。这里的捕获方式分为两种，一种是主动捕获，一种是被动捕获：

1、主动方式

        顾名思义，当内存溢出发生后，通过指令的方式手机当前应用程序下的内存使用情况。

1、通过（Linux） ps -ef|grep find 或者 （Dos）netstat -ano|findstr 查找java程序运行的PID

2、使用指令收集dump：jmap -dump:format=b,file=路径/heapdump.hprof  查到的PID

注意：主动获取dump文件必须是一出现内存异常就获取dump文件，这样获取的文件信息才比较准确。如果无法及时获取，推荐通过第二种方式获取dump文件。

2、被动方式

        该方式是启动Java服务时，增加额外参数。当程序发生内存溢出时自动收集dump文件：

1、-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/oom/heapdump.hprof

        配置好后，调用我们预先模拟的内存溢出接口

        稍等片刻控制台开始打印日志，提示出现内存溢出并且已经收集到dump文件到指定目录：

四、分析dump文件

        打开下载好的mat软件，通过file-open打开抓取到的dump文件（hprof文件）

        点击切换视图，可以看到内存占用百分之八十是因为这个线程，继续点开发现是一个超大的字符串"AikesAikesAikes...."

        此时我们已经发现了内存溢出的直接原因，接下来要寻找出现这个问题的代码在哪里。再返回到最初的大饼图，点击最下面的details。然后点击See stacktrace 堆叠追踪。

        这里可以看到完整的堆栈信息，里面可以发现我们增加模拟溢出代码的那个Java文件，并且爆发内存溢出的代码行也可以对上，至此溢出分析结束。

总结

        模拟的内存溢出针对性很强，并且我们抓取dump文件也很及时，所以在分析的时候很简单。实际使用过程中面对的陷阱很多，需要从诸多可能中排查幕后凶手。Mat工具功能还很多，目前只是粗略的使用，后续如果有新的发现会继续补充到博文中。

一、背景

最近在进行一个模块的开发时，在测试环境中测试没问题，然后在发布到生产环境后，经常发生堆内存溢出的错误导致服务挂了，需要排查出错误的源头。

二、排查思路

1. 加大堆内存参数。通过修改docker-compose.yml文件参数调大jvm的堆内存大小。并且把错误发生时的快照保存进文件，以便重现时进行分析。(本模块是基于容器化部署)

   environment:
         - JAVA_OPTIONS=-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Xmx4096m

2. 当加大堆内存后，仍然发生了堆内存溢出，此时我们就需要获取到对应的内存快照进行分析。此时我们可以在/tmp目录下获取到对应生成的文件java_pid1.hprof。
3. 选择一款合适的jvm内存分析软件对java_pid1.hprof进行解析分析。

三、jvm分析软件

本次排查过程采用的软件是jvisualvm，这是一款jdk8的bin目录下自带的一个分析工具，使用这个工具我们可以用来分析hprof文件。进入bin目录后，使用jvisualvm命令即可打开该软件

cd /usr/bin
jvisualvm

进入软件后，点击左上角的图标，即可装入hprof文件

选择生成的hprof文件装入后：

然后点击查看异常抛出的线程。

然后就在该线程下找到了一个熟悉的方法，发现原来有个地方一次性从数据库中查询了几十万的数据返回，导致一下子就把堆内存撑爆了，然后找到类似的地方也修改了。之所以在测试环境中没问题，是因为测试环境数据量不多。至此问题排查结束，修改对应的代码就完事了。

线上的一个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();
}

修改后上线观察…