引言

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

OOM 的本質(zhì)：JVM 內(nèi)存模型

OOM的本質(zhì)是JVM某一內(nèi)存區(qū)域的使用超出了其配置或物理資源限制。根據(jù)《Java虛擬機(jī)規(guī)范》，JVM運(yùn)行時(shí)數(shù)據(jù)區(qū)分為以下5個(gè)部分，不同區(qū)域的內(nèi)存溢出對(duì)應(yīng)不同類型的OOM：

其中，堆內(nèi)存OOM、方法區(qū)OOM和虛擬機(jī)棧OOM是日常開發(fā)中最容易踩坑的三類問題，占OOM異?？偭康?/span>90%以上。下文將針對(duì)這三類核心問題，結(jié)合案例展開分析。

案例

堆內(nèi)存 OOM（Java heap space）：對(duì)象無(wú)法回收的重災(zāi)區(qū)

堆內(nèi)存是JVM中最大的內(nèi)存區(qū)域，用于存儲(chǔ)對(duì)象實(shí)例。當(dāng)創(chuàng)建的對(duì)象數(shù)量超過堆內(nèi)存的承載能力，且垃圾回收器（GC）無(wú)法回收足夠空間時(shí)，就會(huì)拋出java.lang.OutOfMemoryError: Java heap space。

場(chǎng)景 1：無(wú)邊界集合存儲(chǔ)對(duì)象

開發(fā)中若使用ArrayList、HashMap等集合時(shí)不限制大小，持續(xù)添加對(duì)象且未及時(shí)清理，會(huì)導(dǎo)致集合占用的內(nèi)存不斷膨脹，最終觸發(fā)堆OOM。

public class HeapOOMCase {
    // 定義一個(gè)占用內(nèi)存的對(duì)象
    static class BigObject {
        // 每個(gè)對(duì)象占用100KB內(nèi)存（102400字節(jié)）
        private byte[] data = new byte[1024 * 100];
    }

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

場(chǎng)景 2：內(nèi)存泄漏導(dǎo)致對(duì)象無(wú)法回收

內(nèi)存泄漏是堆OOM的隱形殺手—— 對(duì)象雖已不再被使用，但因存在無(wú)效引用鏈（如靜態(tài)集合引用、線程池未關(guān)閉的線程引用），導(dǎo)致GC無(wú)法回收，最終耗盡堆內(nèi)存。

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

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

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

排查與解決步驟

1. 開啟堆轉(zhuǎn)儲(chǔ)（Heap Dump）：在JVM啟動(dòng)參數(shù)中添加-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./heapdump.hprof，當(dāng)OOM發(fā)生時(shí)自動(dòng)生成堆內(nèi)存快照文件。
2. 分析快照文件：使用VisualVM（JDK 自帶）或MAT（Eclipse Memory Analyzer）工具打開heapdump.hprof，查看：

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

3. 解決措施：

• 對(duì)集合設(shè)置合理大小上限（如使用LinkedBlockingQueue的有界構(gòu)造函數(shù)）；
• 及時(shí)清理無(wú)效引用（如靜態(tài)集合使用后調(diào)用clear()，或改用弱引用WeakHashMap）；
• 優(yōu)化對(duì)象創(chuàng)建邏輯（如使用對(duì)象池復(fù)用頻繁創(chuàng)建的對(duì)象）。

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

方法區(qū)（JDK 8及以后用Metaspace實(shí)現(xiàn)，取代了原有的永久代）用于存儲(chǔ)類的元信息（如類名、字段、方法字節(jié)碼）、常量池、靜態(tài)變量等。當(dāng)加載的類數(shù)量過多或常量池過大，超出Metaspace的內(nèi)存限制時(shí)，會(huì)拋出java.lang.OutOfMemoryError: Metaspace。

場(chǎng)景 1：動(dòng)態(tài)生成類未控制（如反射、CGLIB）

框架（如Spring、Hibernate）或自定義代碼中若頻繁使用CGLIB動(dòng)態(tài)生成代理類，且未及時(shí)卸載，會(huì)導(dǎo)致方法區(qū)中類元信息累積，觸發(fā)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;
        // 循環(huán)生成代理類，直到Metaspace溢出
        while (true) {
            Object proxy = enhancer.create();
            System.out.println("生成第" + (++count) + "個(gè)代理類");
        }
    }
}

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

JDK 7后，字符串常量池從方法區(qū)移至堆內(nèi)存，但方法區(qū)仍存儲(chǔ)其他常量（如Integer常量池）。若頻繁調(diào)用String.intern()且字符串重復(fù)度低，會(huì)導(dǎo)致常量池膨脹（間接影響方法區(qū)）。

排查與解決步驟

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

• 限制動(dòng)態(tài)類生成數(shù)量（如框架中控制代理類的緩存與復(fù)用）；
• 合理配置Metaspace參數(shù)（-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m，避免無(wú)限制增長(zhǎng)）；
• 避免自定義類加載器的內(nèi)存泄漏（如確保類加載器能被GC回收）。

虛擬機(jī)棧 OOM（Stack size too small）：方法調(diào)用過深的盲區(qū)

虛擬機(jī)棧為每個(gè)線程的方法調(diào)用提供內(nèi)存支持，每個(gè)方法執(zhí)行時(shí)會(huì)創(chuàng)建一個(gè)棧幀（存儲(chǔ)局部變量、操作數(shù)棧等）。當(dāng)方法遞歸調(diào)用過深（棧幀數(shù)量超過棧深度限制）或線程數(shù)量過多（總棧內(nèi)存超出物理內(nèi)存）時(shí)，會(huì)拋出java.lang.StackOverflowError（本質(zhì)是棧內(nèi)存溢出的特殊形式）或java.lang.OutOfMemoryError: Stack size too small。

場(chǎng)景 1：無(wú)限遞歸調(diào)用

遞歸是棧溢出的最常見原因 —— 若遞歸沒有終止條件，或終止條件無(wú)法觸發(fā)，會(huì)導(dǎo)致棧幀不斷壓入虛擬機(jī)棧，最終超出棧深度限制。

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

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

場(chǎng)景 2：創(chuàng)建過多線程

每個(gè)線程都有獨(dú)立的虛擬機(jī)棧（默認(rèn)大小為1MB~10MB）。若創(chuàng)建大量線程（如超過1000 個(gè)），總棧內(nèi)存會(huì)超出物理內(nèi)存限制，觸發(fā)OOM。

排查與解決步驟

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

• 修復(fù)遞歸邏輯，確保有明確的終止條件（如遞歸深度限制）；
• 使用線程池替代手動(dòng)創(chuàng)建線程（如ThreadPoolExecutor，控制線程數(shù)量上限）；
• 合理配置棧大?。?/span>-Xss128k，減小單個(gè)線程棧大小，但需避免過小導(dǎo)致正常調(diào)用溢出）。

OOM 問題的通用預(yù)防策略

合理配置 JVM 內(nèi)存參數(shù)

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

監(jiān)控與預(yù)警

接入APM工具（如 SkyWalking、Prometheus+Grafana），監(jiān)控JVM內(nèi)存（堆、方法區(qū)、直接內(nèi)存）、線程數(shù)量、GC頻率等指標(biāo)，設(shè)置閾值預(yù)警（如堆內(nèi)存使用率超過90%時(shí)告警），提前發(fā)現(xiàn)潛在OOM風(fēng)險(xiǎn)。