在Java开发过程中，OutOfMemoryError（简称 OOM）是令开发者头疼的常见问题之一。它并非单一类型的错误，而是一组因JVM内存资源耗尽而抛出的异常集合。许多开发者在遇到OOM时，往往因缺乏系统认知而难以快速定位根源。

OOM 的本质：JVM 内存模型

OOM的本质是JVM某一内存区域的使用超出了其配置或物理资源限制。根据《Java虚拟机规范》，JVM运行时数据区分为以下5个部分，不同区域的内存溢出对应不同类型的OOM：

内存区域	作用	可能抛出的 OOM 类型
堆内存（Heap）	存储对象实例与数组	Java heap space
方法区（Metaspace）	存储类元信息、常量、静态变量等	Metaspace
虚拟机栈（VM Stack）	存储方法调用栈帧（局部变量、操作数栈）	StackOverflowError/Stack size too small
本地方法栈（Native Stack）	为 Native 方法提供内存支持	OutOfMemoryError（较少见）
程序计数器（PC）	记录当前线程执行的字节码指令地址	无 OOM（唯一不会抛出 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 查看线程栈轨迹，定位无限递归的方法；使用jconsole监控线程数量。
2. 解决措施：

• 修复递归逻辑，确保有明确的终止条件（如递归深度限制）；
• 使用线程池替代手动创建线程（如ThreadPoolExecutor，控制线程数量上限）；
• 合理配置栈大小（-Xss128k，减小单个线程栈大小，但需避免过小导致正常调用溢出）。

OOM 问题的通用预防策略

OOM 问题的通用预防策略

-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风险。