记录一次Java OOM内存溢出排查全流程

出现问题

2022年10月11号下午三点多，客户那边发来消息服务器接口无响应，需要查看

定位问题

使用远程连接工具登录上服务器之后，首先执行free -h 和 df -h查看服务器的内存以及磁盘空间是否充足，如下图

发现磁盘以及系统内存使用情况率正常，于是先使用ps -ef|grep java 查找有问题的进程id号，再使用jmap -heap pid(进程id) 查看堆内存使用情况，发现老年代已经满了并且因为JVM参数开启了自动打印OOM的文件，找到了OOM文件，所以知道了系统是发生了OOM异常

分析问题

使用ll -h 命令可以展示出便于"人类"看的懂格式，例如文件大小，可以看到这个文件大小超过了2G，使用sz 文件名 命令下载到自己电脑上面来进行分析

使用Java VisualVM工具分析

这个是jdk自带的工具，我们可以在jdk安装目录下的bin目录下找到jvisualvm.exe程序，双击打开
打开之后点击装入，选择hprof文件

等待程序右下角加载完毕，如果加载很慢的话可以去适当修改visualvm的运行内存大小提高速度jdk\lib\visualvm\etc\visualvm.conf

解析完成之后点击类，可以查看到具体是哪个线程发生了OOM，点击可以看到具体的堆栈信息查询是哪个业务导致

还可以点击类页签，可以看到我们自己的业务对象占用了 20% 的堆内存空间，到这里真相就浮出水面了

点击业务对象可以进到实例数页签，发现该实例有29W个，占用堆内存400M+，恐怖如斯

结合具体业务解决问题

查询堆栈代码发现堆内这些业务对象确实是这个线程产生的，分析代码发现这个业务是导出所有的数据生成excel表，mysql表中有14W+的数据，虽然对于表来说毫无压力，但是全量查询到内存中占用空间还是挺大的，并且到后期表数据越多导出的数据越多也越容易OOM

假如我们JVM堆内存过小的话我们可以通过增加堆内存空间来解决，不过这个业务对象400M，多来几次并发也会OOM，并且堆内存空间我们已经是2G了，过大的内存空间也会导致full gc时间变长，先从业务角度分析能否优化

和客户讨论方案

有两个方案向客户提出：
1、导出的时候强制用户选择导出时间区间条件，减少数据量的查询，分批导出
2、后台进行限制，每次导出最多只能导出不超过10000条数
最终选择方案2进行了修改

总结

在解决问题的过程中需要多思考，想想这样做会有什么后果，可不可行再去执行，每个人遇到的问题都是不一样的，知识是基础，具体解决方案需要根据具体情况来确定。

后续补充

根本解决：更好的解决方案是修改操作excel的类使用，使用SXSSFWorkbook类进行操作，自定义内存中存多少行数据，从而减少大幅度内存占用。

Java VisualVM相比于MemoryAnalyzerTools来说还是有一定的局限性的，MemoryAnalyzerTools可以根据线程占用内存大小来进行排序并且查看堆栈信息，可以更快速定位异常代码。