問題:
- 最近在解決公司出現的Excel導出,內存溢出問題
一.查看服務器配置信息
該服務分配了1G的內存空間
二.分析解決問題
- 查看當前採用的導出方式是什麼,發現採用的是HSSF,如果對POI導出不是很瞭解的可以看一下我之前的文章
- 初步判斷造成內存溢出的原因是由於這個造成
- 決定採用SXSSF的方式進行導出(對代碼的修改量非常的小)
4. 本地測試正常
5. 使用docker推送到遠程服務上,測試接口,報錯,異常如下
Caused by: java.lang.NullPointerException
at sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
at sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:219)
at sun.awt.FontConfiguration.init(FontConfiguration.java:107)
at sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:774)
at sun.font.SunFontManager$2.run(SunFontManager.java:431)
at java.security.AccessController.doPrivileged(Native Method)
at sun.font.SunFontManager.<init>(SunFontManager.java:376)
at sun.awt.FcFontManager.<init>(FcFontManager.java:35)
at sun.awt.X11FontManager.<init>(X11FontManager.java:57)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at sun.font.FontManagerFactory$1.run(FontManagerFactory.java:83)
at java.security.AccessController.doPrivileged(Native Method)
at sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74)
at java.awt.Font.getFont2D(Font.java:491)
at java.awt.Font.canDisplayUpTo(Font.java:2060)
at java.awt.font.TextLayout.singleFont(TextLayout.java:470)
at java.awt.font.TextLayout.<init>(TextLayout.java:531)
at org.apache.poi.ss.util.SheetUtil.getDefaultCharWidth(SheetUtil.java:254)
at org.apache.poi.xssf.streaming.AutoSizeColumnTracker.<init>(AutoSizeColumnTracker.java:117)
at org.apache.poi.xssf.streaming.SXSSFSheet.<init>(SXSSFSheet.java:77)
at org.apache.poi.xssf.streaming.SXSSFWorkbook.createAndRegisterSXSSFSheet(SXSSFWorkbook.java:636)
at org.apache.poi.xssf.streaming.SXSSFWorkbook.createSheet(SXSSFWorkbook.java:629)
at org.apache.poi.xssf.streaming.SXSSFWorkbook.createSheet(SXSSFWorkbook.java:71)
at com.xfn.mf.utils.ExcelUtils1.exportExcel(ExcelUtils1.java:85)
at com.xfn.mf.service.xfnImpl.ExcelServiceImpl.exportAssSubOne(ExcelServiceImpl.java:1492)
at com.xfn.mf.service.xfnImpl.ExcelServiceImpl.lambda$degradeExportAssSubOne$9(ExcelServiceImpl.java:1357)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
... 1 more
三.分析異常信息
- 查看拋出異常的代碼位置
異常:
com.xfn.mf.utils.ExcelUtils1.exportExcel(ExcelUtils1.java:85)
出現異常的代碼:
Sheet sh = wb.createSheet(sheetName);
- 發現是使用SXSSFWorkbook創建Sheet時拋出的異常,判斷是否是SXSSFWorkbook初始化失敗,在初始化之後增加打印語句
代碼:
Workbook wb = new SXSSFWorkbook(100);
System.out.println("SXSSFWorkbook:" + wb);
輸出結果:
SXSSFWorkbook:org.apache.poi.xssf.streaming.SXSSFWorkbook@59dbef45
-
發現並不是SXSSFWorkbook初始化失敗
-
思考:理論上這種Apache的三方工具,不可能不做非空校驗的,並且我本地可以正常運行,使用的還是docker,理論上本地的環境應該和服務器上的環境是一樣的,那麼代碼還有環境都一樣那會是什麼原因
四.分析源碼嘗試找出問題
- 決定從出現異常的地方開始,看一下他的源碼
Sheet sh = wb.createSheet(sheetName);
- 源碼分析過程圖
- 似乎這裏的源碼和本地出現了差異,並且出現差異的地方似乎和JDK有關,於是我查看了一下服務器的JDK版本,發現採用的是opeanjdk 1.8 似乎 和本地的jdk1.8好像沒有什麼區別
- 到此思路又斷了,難道是opeanjdk 和 jdk 是有差異的?(這個之前並沒有去了解過,只知道Linux下自帶的是opeanjdk),發現opeanjdk相較於jdk更加的弱小,功能沒有那麼的齊全
- 感覺問題好像就是opeanjdk在字體方法的支持度不夠,而本地的sun jdk可以獲取到更全的字體信息,但是無法修改jdk的版本,所以手動在容器中下載字體庫
RUN apk add --update font-adobe-100dpi ttf-dejavu fontconfig
- 重新部署到容器中,發現可以成功運行
五.總結
- 當出現異常時,合理分析,但是當思路中斷時,可以查看一下源碼,按照報錯的代碼行數,一步步定位可能出現問題的地方
- opeanjdk的功能是沒有jdk齊全的,具體內容有空了解