记一次内存溢出排查(OutOfMemoryError)和jvm调优

2024-03-13 11:57:15

项目场景：

上传Excel文件到阿里云的oss，定时任务进行异步下载进行文件解析。异步下载文件返回的是InputStream，项目里用了Apache.POI XSSFWorkbook进行转化，并对Excel中的sheet进行数据解析，然后异步写入es，大概就是这么一个场景。

问题描述：

资源泄漏：使用Apache.POI XSSFWorkbook时，工作簿永远不会被关闭(Resource leak: workbook is never closed warning when using Apache.POI XSSFWorkbook)，需要自己手动的进行关闭，否则会打满内存。

原因分析与解决方案：

1.首先出现问题的当天下午，邮件一直在报警：如图所示：

第一反应就是该服务的健康检查不通过，说明服务可能挂了。
2.打开线上服务的error日志，发现日志里有如下错误：

我们可以发现，其中最关键的一行错误日志：java.lang.OutOfMemoryError: Java heap space，没错，就是比较常见但是大家又不想见到的堆内存溢出。
3.内存溢出肯定是项目里某个代码不合理造成的内存没有及时释放导致的，第一想法就是如何能搞到dump文件，一般线上服务器我们是没有权限的，我们需要找运维帮忙把dump文件弄出来，正一筹莫展的时候，我发现日志目录里有如下文件：

有一个gc.log和java_pid13327.hprof的文件，正如文件名称的理解，gc.log应该是gc的日志记录，.hprof结尾的文件是java进程13327的dump文件，所以第一想法就是把这个java_pid13327.hprof文件导出来，但是线上我没有权限，所以我马上联系运维人员帮忙把这个文件导出来
4.文件导出来后，用mat分析工具进行内存分析，感兴趣的同学可以在网上下载mat分析工具，然后打开相应的hprof文件即可，如图：

我们可以发现，总共938.4M的内存，有绝大部分是以下使用的：

我们可以看到schedule-thread这个线程名称，这应该是项目里用到了@Scheduled注解，默认的线程名称，由此马上想到应该是定时任务那块出了问题，接下来我们可以看看具体的内存占用情况，看是否符合我们的猜想，如图：

打开outgoing references的选项，然后可以看到：

org.apache.poi.xssf.usermodel.XSSFSheet这一块占用了大量的内存，于是我们马上查看代码，发现代码里Workbook wb = new XSSFWorkbook(inputStream)这样的语句没有进行wb.close()操作，经过查阅资料，我们可以发现：

XSSFWorkbook这个是需要手动关闭的，不然就会占用内存直到内存溢出。
4.问题排查到了，马上修复代码，平常我们可能会在finally里做处理，如下：

Workbook wb = null;
try{
 wb = new XSSFWorkbook(inputStream)
} catch() {
	//TODO
}
finally {
      try {
           if (Objects.nonNull(workbook)) {
               workbook.close();
           }
       } catch (IOException e) {
           log.error("关闭流失败:{}", e.getMessage());
       }
 }

但是现在这种处理方式不建议使用，使用的更多的可能是try-with-resources语句，我们经过查阅资料可以发现如下描述：

所以，我这边，马上改成了这种方式：

try (Workbook wb = new XSSFWorkbook(inputStream)) {
    //TODO
} catch(Exception e) {
    log.error("error:{}", e.getMessage)
}

上面这种操作,使用try-with-resources语句更优雅的关闭资源，发现网上也是推荐这种：

最终改完上线，还是出乎意料之外，还是报java.lang.OutOfMemoryError: Java heap space。所以我马上看了下服务的jvm内存配置，发现-Xms1G -Xmx1G ，发现-Xms：JVM初始分配的内存为1G, -Xmx：JVM最大分配的内存为1G，而我们这边的应用场景是可能随时会上传最大1G的50个文件，所以此时觉得jvm内存肯定不够用，在极端情况，所以马上改成4G，也就是 -Xms4G -Xmx4G，然后重启项目最终得以解决。

总结：

1.关于内存溢出
凡是项目中可能会造成内存溢出的一定要着重CodeReview，处理流相关的一定得关闭。
2.关于dump文件
大家有权限的话，可以先用ps -ef|grep java 检查java进程是否存在，如果存在的话拿到其进程号，然后进行如下操作：
jmap -dump:format=b,file=test.hprof 91969 （导出dump文件，test.hprof是导出的文件名称，91969是java pid）
只要能拿到dump文件，就可以很方便的排查问题
3.关于jvm调优
其实有时候jvm的内存配置是否合理显得尤为重要，既要对自己项目有一个较深的了解，可以评估极端情况下最大的内存占用，从而设置合理的内存配置，我在网上看了下，如下：

具体配置得结合应用场景来设置。所以jvm合理的配置显得尤为重要。

以上是作者的亲身经历，也是经验所得，希望以上内容能够对你有所帮助！喜欢的点个赞吧！

码农公寓

项目场景：

问题描述：

原因分析与解决方案：

总结：

相关文章