前言
前一段時間，公司同僚的一個線上服務
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檔案導入導出功能。
該功能的流程圖如下：
- 使用者通過浏覽器上傳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
-
XSSFWorkbook
-
SXSSFWorkbook
看到了這個類，可以驗證之前我們通過日志分析問題，得出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
6. 後續思考
其實，當時我建議過使用阿裡開源的
EasyExcel
解決OOM的問題。
但同僚說，excel中有很多樣式，在導出的新excel中要保留之前的樣式，同時增加一列，傳回導入的結果。
如果使用
EasyExcel
不太好處理，使用
原始
的
Workbook
更好處理一些。
但是使用mq異步導入excel檔案這套方案，如果并發量大的話，任然可能會出現OOM問題，有安全隐患。
是以，有必要調整一下mq消費者。
後來，mq消費者的
線程池
，設定成
4
個線程消費，避免mq消費者同時處理過多的消息，讀取大量的excel，導緻記憶體占用過多的問題。當然線程個數參數，可以根據實際情況調整。
此外，使用阿裡的
arthas
也可以定位線上OOM問題，後面會有專門的文章介紹，感興趣的小夥伴可以關注一下。