系統穩定性——OutOfMemoryError 常見原因及解決方法

作者：涯海

創作日期：2019-07-15

專欄位址：

【穩定大于一切】

當 JVM 記憶體嚴重不足時，就會抛出 java.lang.OutOfMemoryError 錯誤。本文總結了常見的 OOM 原因及其解決方法，如下圖所示。如有遺漏或錯誤，歡迎補充指正。

如果對 JVM 記憶體模型和垃圾回收機制不熟悉，推薦閱讀

《咱們從頭到尾說一次 Java 垃圾回收》

。

目錄

• Java heap space
• GC overhead limit exceeded
• Permgen space
• Metaspace
• Unable to create new native thread
• Out of swap space？
• Kill process or sacrifice child
• Requested array size exceeds VM limit
• Direct buffer memory
• 推薦工具&産品
• 參考文章
• 加入我們

1. Java heap space

當堆記憶體（Heap Space）沒有足夠空間存放新建立的對象時，就會抛出

java.lang.OutOfMemoryError: Java heap space

錯誤（根據實際生産經驗，可以對程式日志中的 OutOfMemoryError 配置關鍵字告警，一經發現，立即處理）。

原因分析

Java heap 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 也無法回收。

此類問題的原因與解決方案跟

Java heap 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

功能逐一分析開銷最大的 classloader 和重複 class。

4. Metaspace

JDK 1.8 使用 Metaspace 替換了永久代（Permanent Generation），該錯誤表示 Metaspace 已被用滿，通常是因為加載的 class 數目太多或體積太大。

此類問題的原因與解決方法跟

Permgen space

非常類似，可以參考上文。需要特别注意的是調整 Metaspace 空間大小的啟動參數為

-XX:MaxMetaspaceSize

5. Unable to create new native thread

每個 Java 線程都需要占用一定的記憶體空間，當 JVM 向底層作業系統請求建立一個新的 native 線程時，如果沒有足夠的資源配置設定就會報此類錯誤。

JVM 向 OS 請求建立 native 線程失敗，就會抛出

Unable to create new native thread

，常見的原因包括以下幾類：

• 線程數超過作業系統最大線程數 ulimit 限制。
• 線程數超過 kernel.pid_max（隻能重新開機）。
• native 記憶體不足。

該問題發生的常見過程主要包括以下幾步：

1. JVM 内部的應用程式請求建立一個新的 Java 線程；
2. JVM native 方法代理了該次請求，并向作業系統請求建立一個 native 線程；
3. 作業系統嘗試建立一個新的 native 線程，并為其配置設定記憶體；
4. 如果作業系統的虛拟記憶體已耗盡，或是受到 32 位程序的位址空間限制，作業系統就會拒絕本次 native 記憶體配置設定；
5. JVM 将抛出

   java.lang.OutOfMemoryError: Unable to create new native thread

   錯誤。

• 更新配置，為機器提供更多的記憶體；
• 降低 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）兩部分組成。當運作時程式請求的虛拟記憶體溢出時就會報

Out of swap space?

該錯誤出現的常見原因包括以下幾類：

• 位址空間不足；
• 實體記憶體已耗光；
• 應用程式的本地記憶體洩漏（native leak），例如不斷申請本地記憶體，卻不釋放。
• 執行

  jmap -histo:live <pid>

  指令，強制執行 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 錯誤，

Kill process or sacrifice 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，一旦使用超出限制，就會抛出

Direct buffer memory

• Java 隻能通過 ByteBuffer.allocateDirect 方法使用 Direct ByteBuffer，是以，可以通過 等線上診斷工具攔截該方法進行排查。
• 檢查是否直接或間接使用了 NIO，如 netty，jetty 等。
• 通過啟動參數

  -XX:MaxDirectMemorySize

  調整 Direct ByteBuffer 的上限值。
• 檢查 JVM 參數是否有

  -XX:+DisableExplicitGC

  選項，如果有就去掉，因為該參數會使

  System.gc()

  失效。
• 檢查堆外記憶體使用代碼，确認是否存在記憶體洩漏；或者通過反射調用

  sun.misc.Cleaner

  的

  clean()

  方法來主動釋放被 Direct ByteBuffer 持有的記憶體空間。
• 記憶體容量确實不足，更新配置。

• Eclipse Memory Analyzer —— JVM 記憶體分析工具
• ARMS —— 阿裡雲 APM 産品，支援 OOM 異常關鍵字告警
• Arthas —— Java 線上診斷工具

• Plumbr OutOfMemoryError（推薦，含代碼示例）
• GCeasy OutOfMemoryError
• JVM 記憶體結構

【穩定大于一切】打造國内穩定性領域知識庫，讓無法解決的問題少一點，讓世界的确定性多一點。

• 【穩定大于一切】GitHub 位址
• 【穩定大于一切】雲栖社群