當 JVM 內存嚴重不足時,就會拋出 java.lang.OutOfMemoryError 錯誤。本文總結了常見的 OOM 原因及其解決方法,如下圖所示。如有遺漏或錯誤,歡迎補充指正。
1、Java heap space
當堆內存(Heap Space)沒有足夠空間存放新創建的對象時,就會拋出 java.lang.OutOfMemoryError:Javaheap space 錯誤(根據實際生產經驗,可以對程序日誌中的 OutOfMemoryError 配置關鍵字告警,一經發現,立即處理)。
原因分析
Javaheap space 錯誤產生的常見原因可以分為以下幾類:
- 請求創建一個超大對象,通常是一個大數組。
- 超出預期的訪問量/數據量,通常是上游系統請求流量飆升,常見於各類促銷/秒殺活動,可以結合業務流量指標排查是否有尖狀峰值。
- 過度使用終結器(Finalizer),該對象沒有立即被 GC。
- 內存洩漏(Memory Leak),大量對象引用沒有釋放,JVM 無法對其自動回收,常見於使用了 File 等資源沒有回收。
解決方案
針對大部分情況,通常只需要通過 -Xmx 參數調高 JVM 堆內存空間即可。如果仍然沒有解決,可以參考以下情況做進一步處理:
- 如果是超大對象,可以檢查其合理性,比如是否一次性查詢了數據庫全部結果,而沒有做結果數限制。
- 如果是業務峰值壓力,可以考慮添加機器資源,或者做限流降級。
- 如果是內存洩漏,需要找到持有的對象,修改代碼設計,比如關閉沒有釋放的連接。
2、GC overhead limit exceeded
當 Java 進程花費 98% 以上的時間執行 GC,但只恢復了不到 2% 的內存,且該動作連續重複了 5 次,就會拋出 java.lang.OutOfMemoryError:GC overhead limit exceeded錯誤。簡單地說,就是應用程序已經基本耗盡了所有可用內存, GC 也無法回收。
此類問題的原因與解決方案跟 Javaheap space 非常類似,可以參考上文。
3、Permgen space
該錯誤表示永久代(Permanent Generation)已用滿,通常是因為加載的 class 數目太多或體積太大。
原因分析
永久代存儲對象主要包括以下幾類:
- 加載/緩存到內存中的 class 定義,包括類的名稱,字段,方法和字節碼;
- 常量池;
- 對象數組/類型數組所關聯的 class;
- JIT 編譯器優化後的 class 信息。
PermGen 的使用量與加載到內存的 class 的數量/大小正相關。
解決方案
根據 Permgen space 報錯的時機,可以採用不同的解決方案,如下所示:
- 程序啟動報錯,修改 -XX:MaxPermSize 啟動參數,調大永久代空間。
- 應用重新部署時報錯,很可能是沒有應用沒有重啟,導致加載了多份 class 信息,只需重啟 JVM 即可解決。
- 運行時報錯,應用程序可能會動態創建大量 class,而這些 class 的生命週期很短暫,但是 JVM 默認不會卸載 class,可以設置 -XX:+CMSClassUnloadingEnabled 和 -XX:+UseConcMarkSweepGC這兩個參數允許 JVM 卸載 class。
如果上述方法無法解決,可以通過 jmap 命令 dump 內存對象 jmap-dump:format=b,file=dump.hprof<process-id> ,然後利用 Eclipse MAT https://www.eclipse.org/mat 功能逐一分析開銷最大的 classloader 和重複 class。/<process-id>
4、Metaspace
JDK 1.8 使用 Metaspace 替換了永久代(Permanent Generation),該錯誤表示 Metaspace 已被用滿,通常是因為加載的 class 數目太多或體積太大。
此類問題的原因與解決方法跟 Permgenspace 非常類似,可以參考上文。需要特別注意的是調整 Metaspace 空間大小的啟動參數為 -XX:MaxMetaspaceSize。
5、Unable to create new native thread
每個 Java 線程都需要佔用一定的內存空間,當 JVM 向底層操作系統請求創建一個新的 native 線程時,如果沒有足夠的資源分配就會報此類錯誤。
原因分析
JVM 向 OS 請求創建 native 線程失敗,就會拋出 Unableto createnewnativethread,常見的原因包括以下幾類:
- 線程數超過操作系統最大線程數 ulimit 限制;
- 線程數超過 kernel.pid_max(只能重啟);
- native 內存不足;
該問題發生的常見過程主要包括以下幾步:
- JVM 內部的應用程序請求創建一個新的 Java 線程;
- JVM native 方法代理了該次請求,並向操作系統請求創建一個 native 線程;
- 操作系統嘗試創建一個新的 native 線程,併為其分配內存;
- 如果操作系統的虛擬內存已耗盡,或是受到 32 位進程的地址空間限制,操作系統就會拒絕本次 native 內存分配;
5、JVM 將拋出 java.lang.OutOfMemoryError:Unableto createnewnativethread錯誤。
解決方案
- 升級配置,為機器提供更多的內存;
- 降低 Java Heap Space 大小;
- 修復應用程序的線程洩漏問題;
- 限制線程池大小;
- 使用 -Xss 參數減少線程棧的大小;
- 調高 OS 層面的線程最大數:執行 ulimia-a 查看最大線程數限制,使用 ulimit-u xxx 調整最大線程數限制。
ulimit -a .... 省略部分內容 ..... max user processes (-u) 16384
6、Out of swap space?
該錯誤表示所有可用的虛擬內存已被耗盡。虛擬內存(Virtual Memory)由物理內存(Physical Memory)和交換空間(Swap Space)兩部分組成。當運行時程序請求的虛擬內存溢出時就會報 Outof swap space? 錯誤。
原因分析
該錯誤出現的常見原因包括以下幾類:
- 地址空間不足;
- 物理內存已耗光;
- 應用程序的本地內存洩漏(native leak),例如不斷申請本地內存,卻不釋放。
- 執行 jmap-histo:live
命令,強制執行 Full GC;如果幾次執行後內存明顯下降,則基本確認為 Direct ByteBuffer 問題。
解決方案
根據錯誤原因可以採取如下解決方案:
- 升級地址空間為 64 bit;
- 使用 Arthas 檢查是否為 Inflater/Deflater 解壓縮問題,如果是,則顯式調用 end 方法。
- Direct ByteBuffer 問題可以通過啟動參數 -XX:MaxDirectMemorySize 調低閾值。
- 升級服務器配置/隔離部署,避免爭用。
7、 Kill process or sacrifice child
有一種內核作業(Kernel Job)名為 Out of Memory Killer,它會在可用內存極低的情況下“殺死”(kill)某些進程。OOM Killer 會對所有進程進行打分,然後將評分較低的進程“殺死”,具體的評分規則可以參考 Surviving the Linux OOM Killer。
不同於其他的 OOM 錯誤, Killprocessorsacrifice child 錯誤不是由 JVM 層面觸發的,而是由操作系統層面觸發的。
原因分析
默認情況下,Linux 內核允許進程申請的內存總量大於系統可用內存,通過這種“錯峰複用”的方式可以更有效的利用系統資源。
然而,這種方式也會無可避免地帶來一定的“超賣”風險。例如某些進程持續佔用系統內存,然後導致其他進程沒有可用內存。此時,系統將自動激活 OOM Killer,尋找評分低的進程,並將其“殺死”,釋放內存資源。
解決方案
- 升級服務器配置/隔離部署,避免爭用。
- OOM Killer 調優。
8、Requested array size exceeds VM limit
JVM 限制了數組的最大長度,該錯誤表示程序請求創建的數組超過最大長度限制。
JVM 在為數組分配內存前,會檢查要分配的數據結構在系統中是否可尋址,通常為 Integer.MAX_VALUE-2。
此類問題比較罕見,通常需要檢查代碼,確認業務是否需要創建如此大的數組,是否可以拆分為多個塊,分批執行。
9、Direct buffer memory
Java 允許應用程序通過 Direct ByteBuffer 直接訪問堆外內存,許多高性能程序通過 Direct ByteBuffer 結合內存映射文件(Memory Mapped File)實現高速 IO。
原因分析
Direct ByteBuffer 的默認大小為 64 MB,一旦使用超出限制,就會拋出 Directbuffer memory 錯誤。
解決方案
- Java 只能通過 ByteBuffer.allocateDirect 方法使用 Direct ByteBuffer,因此,可以通過 Arthas 等在線診斷工具攔截該方法進行排查。
- 檢查是否直接或間接使用了 NIO,如 netty,jetty 等。
- 通過啟動參數 -XX:MaxDirectMemorySize 調整 Direct ByteBuffer 的上限值。
- 檢查 JVM 參數是否有 -XX:+DisableExplicitGC 選項,如果有就去掉,因為該參數會使 System.gc() 失效。
- 檢查堆外內存使用代碼,確認是否存在內存洩漏;或者通過反射調用 sun.misc.Cleaner 的 clean() 方法來主動釋放被 Direct ByteBuffer 持有的內存空間。
- 內存容量確實不足,升級配置。
推薦工具&產品
JVM 內存分析工具 mat
1、Eclipse Memory Analyzer
https://www.eclipse.org/mat
(a)(li)(雲) APM 產品,支持 OOM 異常關鍵字告警
2、ARMS
https://help.aliyun.com/document_detail/42966.html?spm=a2c4g.11174283.6.685.d69b668cuztvff
阿里 Java 在線診斷工具 Arthas(阿爾薩斯)
3、alibaba Arthas
https://github.com/alibaba/arthas
參考文章
1、Plumbr OutOfMemoryError(推薦,含代碼示例)
2、GCeasy OutOfMemoryError
3、JVM 內存結構
共同進步,學習分享
歡迎大家關注我的公眾號【風平浪靜如碼】,海量Java相關文章,學習資料都會在裡面更新,整理的資料也會放在裡面。
覺得寫的還不錯的就點個贊,加個關注唄!點關注,不迷路,持續更新!!!
海量面試、架構資料分享
閱讀更多 愛喝王老吉的劉某人 的文章