以下是 Java 內(nèi)存溢出（OOM）的常見原因及對應(yīng)的解決方法，結(jié)合實戰(zhàn)案例和代碼示例說明：

一、堆內(nèi)存溢出（Java heap space）

1. 常見原因

• 對象創(chuàng)建過多：循環(huán)中不斷創(chuàng)建新對象，導(dǎo)致堆內(nèi)存耗盡。
• 內(nèi)存泄漏：對象無法被 GC 回收（如靜態(tài)集合持有對象引用、資源未關(guān)閉）。
• 大對象分配：數(shù)組、集合等占用內(nèi)存過大，超過堆空間限制。

2. 示例代碼（觸發(fā)堆溢出）

import java.util.ArrayList;
import java.util.List;

public class HeapOOM {
    public static void main(String[] args) {
        List<byte[]> list = new ArrayList<>();
        while (true) {
            // 每次創(chuàng)建1MB對象
            list.add(new byte[1024 * 1024]); 
        }
    }
}

3. 解決方法

增加堆內(nèi)存：

java -Xms2g -Xmx2g -jar app.jar  # 初始和最大堆均為2GB

優(yōu)化對象生命周期：

• 避免在循環(huán)中創(chuàng)建大對象。
• 使用對象池（如 Apache Commons Pool）重用對象。

排查內(nèi)存泄漏：

• 通過 MAT（Memory Analyzer Tool）分析堆轉(zhuǎn)儲文件，找出泄漏點。
• 檢查靜態(tài)集合（如static List）是否持有對象引用。

二、Metaspace 溢出（Metaspace）

1. 常見原因

• 動態(tài)生成類過多：如大量使用反射、CGLIB 代理、字節(jié)碼框架（如 ASM）。
• 類加載器未釋放：自定義類加載器加載的類無法被卸載。
• Metaspace 空間設(shè)置過小：默認無上限，但可能受系統(tǒng)內(nèi)存限制。

2. 示例代碼（觸發(fā) Metaspace 溢出）

import net.sf.cglib.proxy.Enhancer;
import net.sf.cglib.proxy.MethodInterceptor;

public class MetaspaceOOM {
    public static void main(String[] args) {
        while (true) {
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(Object.class);
            enhancer.setUseCache(false);
            enhancer.setCallback((MethodInterceptor) (obj, method, args1, proxy) -> proxy.invokeSuper(obj, args1));
            enhancer.create();  // 動態(tài)生成代理類
        }
    }
}

3. 解決方法

增加 Metaspace 大小：

java -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -jar app.jar

避免重復(fù)生成類：

• 緩存動態(tài)生成的類（如 Hibernate 的BytecodeProvider）。
• 減少反射調(diào)用頻率。

排查類加載器泄漏：

• 確保自定義類加載器正確釋放資源。
• 使用jstat -class <pid>監(jiān)控類加載數(shù)量。

三、棧溢出（StackOverflowError）

1. 常見原因

• 遞歸過深：方法調(diào)用鏈過長（如無終止條件的遞歸）。
• ?？臻g設(shè)置過小：默認?？臻g（如 Linux 下為 1MB）無法滿足復(fù)雜調(diào)用。

2. 示例代碼（觸發(fā)棧溢出）

public class StackOverflow {
    public static void main(String[] args) {
        recursiveCall();
    }

    private static void recursiveCall() {
        recursiveCall();  // 無限遞歸
    }
}

3. 解決方法

增加?？臻g：

java -Xss2m -jar app.jar  # ?？臻g設(shè)置為2MB

優(yōu)化遞歸邏輯：

• 將遞歸改為迭代（如使用棧數(shù)據(jù)結(jié)構(gòu)模擬遞歸）。
• 添加終止條件，避免無限遞歸。

排查內(nèi)存占用大的局部變量：

• 減少方法中大型數(shù)組或?qū)ο蟮氖褂谩?/li>

四、直接內(nèi)存溢出（Direct buffer memory）

1. 常見原因

• NIO 直接內(nèi)存使用過多：ByteBuffer.allocateDirect()分配的內(nèi)存超出限制。
• 未釋放直接內(nèi)存：DirectByteBuffer對象被 GC 回收，但物理內(nèi)存未釋放。
• 直接內(nèi)存上限設(shè)置過小：默認與堆內(nèi)存相同（-Xmx）。

2. 示例代碼（觸發(fā)直接內(nèi)存溢出）

import java.nio.ByteBuffer;
import java.util.ArrayList;
import java.util.List;

public class DirectMemoryOOM {
    public static void main(String[] args) {
        List<ByteBuffer> buffers = new ArrayList<>();
        while (true) {
            // 每次分配100MB直接內(nèi)存
            ByteBuffer buffer = ByteBuffer.allocateDirect(100 * 1024 * 1024);
            buffers.add(buffer);
        }
    }
}

3. 解決方法

限制直接內(nèi)存大小：

java -XX:MaxDirectMemorySize=512m -jar app.jar

手動釋放直接內(nèi)存：

import sun.misc.Cleaner;
import java.nio.ByteBuffer;

public class DirectMemoryRelease {
    public static void release(ByteBuffer buffer) {
        if (buffer.isDirect()) {
            Cleaner cleaner = ((sun.nio.ch.DirectBuffer) buffer).cleaner();
            if (cleaner != null) {
                cleaner.clean();  // 手動釋放直接內(nèi)存
            }
        }
    }
}

使用內(nèi)存池：

• 采用 Netty 的PooledByteBufAllocator管理直接內(nèi)存。

五、本地內(nèi)存Native Memory

1. 內(nèi)存溢出類型

java.lang.OutOfMemoryError: unable to create new native thread  // 線程創(chuàng)建失敗
java.lang.OutOfMemoryError: Compressed class space  // 壓縮類空間溢出

2. 核心原因

JNI 本地庫內(nèi)存泄漏：

• Java 通過 JNI 調(diào)用 C/C++ 代碼時，本地庫未正確釋放內(nèi)存。

堆外內(nèi)存分配過多：

• 例如 Netty、MappedByteBuffer 等框架直接操作堆外內(nèi)存，超出系統(tǒng)限制。

壓縮類空間不足：

• JDK 8+ 將類元數(shù)據(jù)分為Klass Metaspace和Compressed Class Space，后者默認 1GB。

3. 解決方法

# 增加壓縮類空間
java -XX:CompressedClassSpaceSize=256m -jar app.jar

# 使用內(nèi)存分析工具（如Native Memory Tracking）
java -XX:NativeMemoryTracking=detail -XX:+PrintNMTStatistics -jar app.jar

五、內(nèi)存溢出排查工具與步驟

生成堆轉(zhuǎn)儲文件：

# 手動觸發(fā)
jmap -dump:format=b,file=heapdump.hprof <pid>

# 自動觸發(fā)（推薦）
java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump.hprof -jar app.jar

分析工具：

• MAT（Memory Analyzer Tool）：

分析堆轉(zhuǎn)儲文件，定位大對象和內(nèi)存泄漏（如 “Leak Suspects” 報告）。

• VisualVM：

實時監(jiān)控內(nèi)存、線程、GC 情況，支持堆轉(zhuǎn)儲分析。

• GC 日志分析：

java -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/data/gc.log -jar app.jar

排查步驟：

• 確認 OOM 類型（堆、Metaspace、棧、直接內(nèi)存）。
• 分析堆轉(zhuǎn)儲文件，找出占用內(nèi)存最大的對象。
• 檢查對象引用鏈，確定是否存在內(nèi)存泄漏。
• 優(yōu)化代碼或調(diào)整 JVM 參數(shù)。

六、預(yù)防措施

合理設(shè)置 JVM 參數(shù)：

java -Xms2g -Xmx2g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m \
     -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump.hprof \
     -jar app.jar

資源管理最佳實踐：

• 使用try-with-resources確保資源關(guān)閉。
• 避免靜態(tài)集合持有長生命周期對象。

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

• 通過 Prometheus+Grafana 監(jiān)控 JVM 指標（如堆使用率、GC 頻率）。
• 設(shè)置告警閾值（如堆使用率超過 80% 時觸發(fā)通知）。

七、典型案例分析

案例 1：某電商系統(tǒng)高峰期頻繁 Full GC

原因：

• 緩存大量商品信息，導(dǎo)致老年代空間不足。

解決：

• 增加堆內(nèi)存至 8GB（-Xmx8g）。
• 優(yōu)化緩存策略，設(shè)置合理過期時間。
• 改用 G1 收集器（-XX:+UseG1GC）。

案例 2：某微服務(wù)框架啟動慢且 OOM

原因：

• Spring 框架動態(tài)生成大量代理類，Metaspace 不足。

解決：

• 設(shè)置-XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=1g。
• 升級 Spring 版本，優(yōu)化類加載機制。

通過以上方法，可系統(tǒng)性解決 Java 內(nèi)存溢出問題。關(guān)鍵在于監(jiān)控分析、代碼優(yōu)化、參數(shù)調(diào)優(yōu)三者結(jié)合，同時建立完善的預(yù)警機制。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論