前言

前一段時間，公司同事的一個線上服務OOM的問題，我覺得挺有意思的，在這里跟大家一起分享一下。

我當時其實也參與了一部分問題的定位。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

1 案發現場

他們有個mq消費者服務，在某一天下午，出現OOM了，導致服務直接掛掉。

當時我們收到了很多內存的報警郵件。

發現問題之后，運維第一時間，幫他們dump了當時的內存快照，以便于開發人員好定位問題。

之后，運維重啟了該服務，系統暫時恢復了正常。

大家都知道，如果出現了線上OOM問題，為了不影響用戶的正常使用，最快的解決辦法就是重啟服務。

但重啟服務治標不治本，只能臨時解決一下問題，如果不找到真正的原因，難免下次在某個不經意的時間點，又會出現OOM問題。

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

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://gitee.com/zhijiantianya/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

2 初步定位問題

當時運維dump下來的內存快照文件有3G多，太大了，由于公司內網限制，沒辦法及時給到開發這邊。

沒辦法，只能先從日志文件下手了。

在查日志之前，我們先查看了prometheus上的服務監控。查到了當時那個mq消費者服務的內存使用情況，該服務的內存使用率一直都比較平穩，從2022-09-26 1429開始，出現了一個明顯的內存飆升情況。

根據以往經驗總結出來的，在追查日志時，時間點是一個非常重要的過濾條件。

所以，我們當時重點排查了2022-09-26 1429前后5秒鐘的日志。

由于這個服務，并發量不大，在那段時間的日志量并不多。

所以，我們很快就鎖定了excel文件導入導出功能。

該功能的流程圖如下：

用戶通過瀏覽器上傳excel，調用文件上傳接口。

該接口會上傳excel到文件服務器。然后將文件url，通過mq消息，發送到mq服務器。

mq消費者消費mq消息，從文件服務器中獲取excel數據，做業務處理，然后把結果寫入新的excel中。

mq消費者將新excel文件上傳到文件服務器，然后發websocket消息通知用戶。

用戶收到通知結果，然后可以下載新的excel。

經過日志分析，時間點剛好吻合，從excel文件導入之后，mq消費者服務的內存使用率一下子飆升。

3. 打不開dump文件

從上面分析我們得出初步的結論，線上mq消費者服務的OOM問題，是由于excel導入導出導致的。

于是，我們查看了相關excel文件導入導出代碼，并沒有發現明顯的異常。

為了找到根本原因，我們不得不把內存快照解析出來。

此時，運維把內存快照已經想辦法發給了相關的開發人員（我的同事）。

那位同事用電腦上安裝的內存分析工具：MAT（Memory Analyzer Tool），準備打開那個內存快照文件。

但由于該文件太大，占了3G多的內存，直接打開失敗了。

MemoryAnalyzer.ini文件默認支持打開的內存文件是1G，后來它將參數-xmx修改為4096m。

修改之后，文件可以打開了，但打開的內容卻有問題。

猛然發現，原來是JDK版本不匹配導致的。

他用的MAT工具是基于SunJDK，而我們生成環境用的OpenJDK，二者有些差異。

SunJDK采用JRL協議發布，而OpenJDK則采用GPL V2協議發布。兩個協議雖然都是開放源代碼的，但是在使用上的不同，GPL V2允許在商業上使用，而JRL只允許個人研究使用。

所以需要下載一個基于OpenJDK版本的MAT內存分析工具。

4. 進一步分析

剛好，另一個同事的電腦上下載過OpenJDK版本的MAT內存分析工具。

把文件發給他幫忙分析了一下。

最后發現org.apache.poi.xssf.usermodel.XSSFSheet類的對象占用的內存是最多的。

目前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，一次性創建了大量的對象。

關鍵代碼如下：

XSSFWorkbookwb=newXSSFWorkbook(newFileInputStream(file));
XSSFSheetsheet=wb.getSheetAt(0);

我們通過MAT內存分析工具，已經確定OOM問題的原因了。接下來，最關鍵的一點是：如何解決這個問題呢？

5. 如何解決問題？

根據我們上面的分析，既然XSSFWorkbook在導入導出大excel文件時，會導致內存溢出。那么，我們改成SXSSFWorkbook不就行了？

關鍵代碼改動如下：

XSSFWorkbookwb=newXSSFWorkbook(newFileInputStream(file));
SXSSFWorkbookswb=newSXSSFWorkbook(wb,100);
SXSSFSheetsheet=(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個線程消費，避免消費者同時處理過多的消息，讀取大量的excel，導致內存占用過多的問題。當然線程個數參數，可以根據實際情況調整。

審核編輯：劉清