糟了，线上服务出现OOM了

深藏阁楼爱情的钟 2024-04-03 11:07 69阅读 0赞

### 前言 ###

前一段时间，公司同事的一个线上服务`OOM`的问题，我觉得挺有意思的，在这里跟大家一起分享一下。

我当时其实也参与了一部分问题的定位。

### 1 案发现场 ###

他们有个`mq`消费者服务，在某一天下午，出现`OOM`了，导致服务直接挂掉。

当时我们收到了很多`内存`的`报警邮件`。

发现问题之后，运维第一时间，帮他们dump了当时的内存快照，以便于开发人员好定位问题。

之后，运维重启了该服务，系统暂时恢复了正常。

大家都知道，如果出现了线上OOM问题，为了不影响用户的正常使用，最快的解决办法就是重启服务。

但重启服务治标不治本，只能临时解决一下问题，如果不找到真正的原因，难免下次在某个不经意的时间点，又会出现OOM问题。

所以，有必要定位一下具体原因。

### 2 初步定位问题 ###

当时运维`dump`下来的`内存快照`文件有`3G`多，太大了，由于公司内网限制，没办法及时给到开发这边。

没办法，只能先从日志文件下手了。

在查日志之前，我们先查看了`prometheus`上的服务监控。查到了当时那个mq消费者服务的内存使用情况，该服务的内存使用率一直都比较平稳，从`2022-09-26 14:16:29`开始，出现了一个明显的内存飙升情况。

根据以往经验总结出来的，在追查日志时，时间点是一个非常重要的过滤条件。

所以，我们当时重点排查了`2022-09-26 14:16:29`前后5秒钟的日志。

由于这个服务，并发量不大，在那段时间的日志量并不多。

所以，我们很快就锁定了excel文件导入导出功能。

该功能的流程图如下：  
![b03e8349d4726333cfdf1c7caf45b934.png][]

1.  用户通过浏览器上传excel，调用文件上传接口。
2.  该接口会上传excel到文件服务器。然后将文件url，通过mq消息，发送到mq服务器。
3.  mq消费者消费mq消息，从文件服务器中获取excel数据，做业务处理，然后把结果写入新的excel中。
4.  mq消费者将新excel文件上传到文件服务器，然后发websocket消息通知用户。
5.  用户收到通知结果，然后可以下载新的excel。

经过日志分析，时间点刚好吻合，从excel文件导入之后，mq消费者服务的内存使用率一下子飙升。

### 3. 打不开dump文件 ###

从上面分析我们得出初步的结论，线上mq消费者服务的OOM问题，是由于excel导入导出导致的。

于是，我们查看了相关excel文件导入导出代码，并没有发现明显的异常。

为了找到根本原因，我们不得不把内存快照解析出来。

此时，运维把内存快照已经想办法发给了相关的开发人员（我的同事）。

那位同事用电脑上安装的内存分析工具：`MAT`（Memory Analyzer Tool），准备打开那个内存快照文件。

但由于该文件太大，占了3G多的内存，直接打开失败了。  
![149d25c0e2101d96407967d62b39db40.png][]  
`MemoryAnalyzer.ini`文件默认支持打开的内存文件是`1G`，后来它将参数`-xmx`修改为`4096m`。

修改之后，文件可以打开了，但打开的内容却有问题。

猛然发现，原来是JDK版本不匹配导致的。

他用的`MAT`工具是基于`SunJDK`，而我们生成环境用的`OpenJDK`，二者有些差异。

> SunJDK采用JRL协议发布，而OpenJDK则采用GPL V2协议发布。两个协议虽然都是开放源代码的，但是在使用上的不同，GPL V2允许在商业上使用，而JRL只允许个人研究使用。

所以需要下载一个基于`OpenJDK`版本的`MAT`内存分析工具。

### 4. 进一步分析 ###

刚好，另一个同事的电脑上下载过`OpenJDK`版本的`MAT`内存分析工具。

把文件发给他帮忙分析了一下。  
![3035ffc52f8001c29e4bd55ba96e6420.png][]  
最后发现org.apache.poi.xssf.usermodel.XSSFSheet类的对象占用的内存是最多的。  
![4ba4ab21847c040e2e3b2bb76158132f.png][]  
目前excel的导入导出功能，大部分是基于`apache`的`POI`技术，而`POI`给我们提供了`WorkBook`接口。

常用的WorkBook接口实现有三种：

*  `HSSFWorkbook`：它是早期使用最多的工具，支持Excel2003以前的版本，Excel的扩展名是.xls。只能导出65535条数据，如果超过最大记录条数会报错，但不会出现内存溢出。
 *  `XSSFWorkbook`：它可以操作Excel2003-Excel2007之间的版本，Excel的扩展名是.xlsx。最多可以导出104w条数据，会创建大量的对象存放到内存中，可能会导致内存溢出。
 *  `SXSSFWorkbook`：它可以操作Excel2007之后的所有版本，Excel的扩展名是.xlsx。 SXSSFWorkbook是streaming版本的XSSFWorkbook，它只会保存最新的rows在内存里供查看，以前的rows都会被写入到硬盘里。用磁盘空间换内存空间，不会导致内存溢出。

看到了这个类，可以验证之前我们通过日志分析问题，得出excel导入导出功能引起OOM的结论，是正确的。

那个引起OOM问题的功能，刚好使用了XSSFWorkbook处理excel，一次性创建了大量的对象。

关键代码如下：

XSSFWorkbook wb = new XSSFWorkbook(new FileInputStream(file));
    XSSFSheet sheet = wb.getSheetAt(0);

我们通过MAT内存分析工具，已经确定OOM问题的原因了。接下来，最关键的一点是：如何解决这个问题呢？

### 5. 如何解决问题？ ###

根据我们上面的分析，既然`XSSFWorkbook`在导入导出大excel文件时，会导致内存溢出。那么，我们改成`SXSSFWorkbook`不就行了？

关键代码改动如下：

XSSFWorkbook wb = new XSSFWorkbook(new FileInputStream(file));
    SXSSFWorkbook swb = new SXSSFWorkbook(wb,100);
    SXSSFSheet sheet = (SXSSFSheet) swb.createSheet("sheet1");

使用SXSSFWorkbook将XSSFWorkbook封装了一层，其中100表示excel一次读入内存的最大记录条数，excel中其余的数据将会生成临时文件保存到磁盘上。这个参数，可以根据实际需要调整。

还有一点非常重要：

sheet.flushRows();

需要在程序的结尾处加上上面的这段代码，不然生成的临时文件是空的。

这样调整之后，问题被暂时解决了。

> 此外，顺便说一句，在使用WorkBook接口的相关实现类时，用完之后，要记得调用`close`方法及时关闭喔，不然也可能会出现OOM问题。

### 6. 后续思考 ###

其实，当时我建议过使用阿里开源的`EasyExcel`解决OOM的问题。

但同事说，excel中有很多样式，在导出的新excel中要保留之前的样式，同时增加一列，返回导入的结果。

如果使用`EasyExcel`不太好处理，使用`原始`的`Workbook`更好处理一些。

但是使用mq异步导入excel文件这套方案，如果并发量大的话，任然可能会出现OOM问题，有安全隐患。

因此，有必要调整一下mq消费者。

后来，mq消费者的`线程池`，设置成`4`个线程消费，避免mq消费者同时处理过多的消息，读取大量的excel，导致内存占用过多的问题。当然线程个数参数，可以根据实际情况调整。

此外，使用阿里的`arthas`也可以定位线上OOM问题，后面会有专门的文章介绍，感兴趣的小伙伴可以关注一下。

### 最后说一句(求关注，别白嫖我) ###

如果这篇文章对您有所帮助，或者有所启发的话，帮忙扫描下发二维码关注一下，您的支持是我坚持写作最大的动力。

求一键三连：点赞、转发、在看。

关注公众号：【苏三说技术】，在公众号中回复：面试、代码神器、开发手册、时间管理有超赞的粉丝福利，另外回复：加群，可以跟很多BAT大厂的前辈交流和学习。

[b03e8349d4726333cfdf1c7caf45b934.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/33a1449dbf3a46ef9e2daf73773b1f36.png
[149d25c0e2101d96407967d62b39db40.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/833095d83afa42eca2a3af21dc4987d1.png
[3035ffc52f8001c29e4bd55ba96e6420.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/e34e5f7b991641aeadcc847b346b6100.png
[4ba4ab21847c040e2e3b2bb76158132f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/03/aa901b24956f44289c363061c739f0bb.png