引言

在Java開發過程中，OutOfMemoryError（簡稱 OOM）是令開發者頭疼的常見問題之一。它并非單一類型的錯誤，而是一組因JVM內存資源耗盡而拋出的異常集合。許多開發者在遇到OOM時，往往因缺乏系統認知而難以快速定位根源。

OOM 的本質：JVM 內存模型

OOM的本質是JVM某一內存區域的使用超出了其配置或物理資源限制。根據《Java虛擬機規范》，JVM運行時數據區分為以下5個部分，不同區域的內存溢出對應不同類型的OOM：

其中，堆內存OOM、方法區OOM和虛擬機棧OOM是日常開發中最容易踩坑的三類問題，占OOM異常總量的90%以上。下文將針對這三類核心問題，結合案例展開分析。

案例

堆內存 OOM（Java heap space）：對象無法回收的重災區

堆內存是JVM中最大的內存區域，用于存儲對象實例。當創建的對象數量超過堆內存的承載能力，且垃圾回收器（GC）無法回收足夠空間時，就會拋出java.lang.OutOfMemoryError: Java heap space。

場景 1：無邊界集合存儲對象

開發中若使用ArrayList、HashMap等集合時不限制大小，持續添加對象且未及時清理，會導致集合占用的內存不斷膨脹，最終觸發堆OOM。

public class HeapOOMCase {
    // 定義一個占用內存的對象
    static class BigObject {
        // 每個對象占用100KB內存（102400字節）
        private byte[] data = new byte[1024 * 100];
    }

    public static void main(String[] args) {
        List<BigObject> objectList = new ArrayList<>();
        // 無限循環添加對象，直到堆內存溢出
        while (true) {
            objectList.add(new BigObject());
            // 模擬業務延遲
            try {
                Thread.sleep(10);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

場景 2：內存泄漏導致對象無法回收

內存泄漏是堆OOM的隱形殺手—— 對象雖已不再被使用，但因存在無效引用鏈（如靜態集合引用、線程池未關閉的線程引用），導致GC無法回收，最終耗盡堆內存。

public class MemoryLeakCase {
    // 靜態集合（生命周期與JVM一致）
    private static List<Object> cache = new ArrayList<>();

    public static void addToCache(Object obj) {
        cache.add(obj); // 只添加不刪除，導致對象永久駐留堆內存
    }

    public static void main(String[] args) {
        // 循環添加臨時對象到靜態緩存
        for (int i = 0; i < 100000; i++) {
            addToCache(new byte[1024 * 100]); // 每個對象100KB
        }
    }
}

排查與解決步驟

1. 開啟堆轉儲（Heap Dump）：在JVM啟動參數中添加-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./heapdump.hprof，當OOM發生時自動生成堆內存快照文件。
2. 分析快照文件：使用VisualVM（JDK 自帶）或MAT（Eclipse Memory Analyzer）工具打開heapdump.hprof，查看：

• 哪些對象占用內存最多（Top Components）；
• 對象的引用鏈（Path to GC Roots），定位內存泄漏的根源。

3. 解決措施：

• 對集合設置合理大小上限（如使用LinkedBlockingQueue的有界構造函數）；
• 及時清理無效引用（如靜態集合使用后調用clear()，或改用弱引用WeakHashMap）；
• 優化對象創建邏輯（如使用對象池復用頻繁創建的對象）。

方法區 OOM（Metaspace）：類加載失控的陷阱

方法區（JDK 8及以后用Metaspace實現，取代了原有的永久代）用于存儲類的元信息（如類名、字段、方法字節碼）、常量池、靜態變量等。當加載的類數量過多或常量池過大，超出Metaspace的內存限制時，會拋出java.lang.OutOfMemoryError: Metaspace。

場景 1：動態生成類未控制（如反射、CGLIB）

框架（如Spring、Hibernate）或自定義代碼中若頻繁使用CGLIB動態生成代理類，且未及時卸載，會導致方法區中類元信息累積，觸發OOM。

public class MetaspaceOOMCase {
    public static void main(String[] args) {
        Enhancer enhancer = new Enhancer();
        enhancer.setSuperclass(MetaspaceOOMCase.class);
        enhancer.setCallback((MethodInterceptor) (obj, method, args1, proxy) -> proxy.invokeSuper(obj, args1));
        
        int count = 0;
        // 循環生成代理類，直到Metaspace溢出
        while (true) {
            Object proxy = enhancer.create();
            System.out.println("生成第" + (++count) + "個代理類");
        }
    }
}

場景 2：常量池過大（如大量字符串 intern ()）

JDK 7后，字符串常量池從方法區移至堆內存，但方法區仍存儲其他常量（如Integer常量池）。若頻繁調用String.intern()且字符串重復度低，會導致常量池膨脹（間接影響方法區）。

排查與解決步驟

1. 查看Metaspace使用情況：通過jstat -gcmetacapacity <PID>命令監控Metaspace的容量、已使用量和峰值。
2. 分析類加載情況：使用jmap -clstats <PID>查看已加載的類數量、大小，定位異常的類加載器（如自定義類加載器未卸載）。
3. 解決措施：

• 限制動態類生成數量（如框架中控制代理類的緩存與復用）；
• 合理配置Metaspace參數（-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m，避免無限制增長）；
• 避免自定義類加載器的內存泄漏（如確保類加載器能被GC回收）。

虛擬機棧 OOM（Stack size too small）：方法調用過深的盲區

虛擬機棧為每個線程的方法調用提供內存支持，每個方法執行時會創建一個棧幀（存儲局部變量、操作數棧等）。當方法遞歸調用過深（棧幀數量超過棧深度限制）或線程數量過多（總棧內存超出物理內存）時，會拋出java.lang.StackOverflowError（本質是棧內存溢出的特殊形式）或java.lang.OutOfMemoryError: Stack size too small。

場景 1：無限遞歸調用

遞歸是棧溢出的最常見原因 —— 若遞歸沒有終止條件，或終止條件無法觸發，會導致棧幀不斷壓入虛擬機棧，最終超出棧深度限制。

public class StackOOMCase {
    // 遞歸方法，無終止條件
    public static void recursiveMethod() {
        recursiveMethod(); // 無限調用自身，棧幀持續增加
    }

    public static void main(String[] args) {
        recursiveMethod();
    }
}

場景 2：創建過多線程

每個線程都有獨立的虛擬機棧（默認大小為1MB~10MB）。若創建大量線程（如超過1000 個），總棧內存會超出物理內存限制，觸發OOM。

排查與解決步驟

1. 查看線程與棧信息：使用jstack <PID>查看線程棧軌跡，定位無限遞歸的方法；使用jconsole監控線程數量。
2. 解決措施：

• 修復遞歸邏輯，確保有明確的終止條件（如遞歸深度限制）；
• 使用線程池替代手動創建線程（如ThreadPoolExecutor，控制線程數量上限）；
• 合理配置棧大小（-Xss128k，減小單個線程棧大小，但需避免過小導致正常調用溢出）。

OOM 問題的通用預防策略

合理配置 JVM 內存參數

-Xms2g -Xmx2g  # 堆內存初始2GB，最大2GB
-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m  # 方法區大小
-Xss128k  # 單個線程棧大小
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./heapdump.hprof  # OOM時生成堆快照

監控與預警

接入APM工具（如 SkyWalking、Prometheus+Grafana），監控JVM內存（堆、方法區、直接內存）、線程數量、GC頻率等指標，設置閾值預警（如堆內存使用率超過90%時告警），提前發現潛在OOM風險。