Java 进程发生 OOM 后为什么还能继续运行

一、问题背景

很多开发者第一次遇到 java.lang.OutOfMemoryError 时，会下意识认为 Java 进程应该像 C/C++ 程序发生致命错误那样直接崩溃退出。但实际生产环境中，经常能看到日志里打印了 OOM 异常，随后服务还在继续对外提供请求，甚至只有个别线程异常，整体进程并未退出。

这背后的原因并不简单，它与 Java 异常体系、JVM 内存模型、线程隔离机制以及垃圾回收行为紧密相关。要准确理解这一现象，必须先区分不同类型的 OOM，再结合具体场景分析堆内溢出时 JVM 的实际行为。

二、OOM 并不是进程退出信号

OutOfMemoryError 在 Java 异常体系中继承自 VirtualMachineError，而 VirtualMachineError 又继承自 Error，并非 Exception。很多人有个误解，认为 Error 类异常一定不可捕获、进程一定会终止。实际上，Error 及其子类虽然表示 JVM 层面的严重问题，但它们仍然是 Throwable 的实例，在语法上完全可以被 catch 捕获。

关键点在于：OOM 通常发生在某次具体的内存分配请求中，而不是整个 JVM 的直接崩溃指令。 当某个线程执行 new 操作时，如果堆中无法分配出足够空间，JVM 会先尝试 GC 回收，若回收后仍然不足，则会向当前线程抛出 OutOfMemoryError。这个异常是“抛给调用方”的，不一定意味着整个进程不可继续。

所以，是否还能继续运行，很大程度上取决于：

• 异常是否被当前线程或上层代码捕获；
• 抛出异常后，线程是否还继续持有导致内存不足的对象引用；
• 其他线程是否依赖了已经损坏的共享状态。

三、从一段示例代码理解现象

下面是一段简单的 Java 示例，用来模拟一个线程不断申请堆内存，最终触发 OOM，同时观察另一个线程的运行状态：

public class JvmOomDemo {
    public static void main(String[] args) {
        // 线程一：持续申请大数组
        new Thread(() -> {
            List<byte[]> list = new ArrayList<>();
            while (true) {
                System.out.println(new Date() + " " + Thread.currentThread().getName() + " ==");
                byte[] b = new byte[1024 * 1024 * 1];
                list.add(b);
                try {
                    Thread.sleep(1000);
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        }).start();
        // 线程二：只打印时间，不申请大内存
        new Thread(() -> {
            while (true) {
                System.out.println(new Date() + " " + Thread.currentThread().getName() + " ==");
                try {
                    Thread.sleep(1000);
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }
}

运行一段时间后，可以看到类似以下输出：

Wed Nov 07 14:42:18 CST 2018 Thread-1 ==
Wed Nov 07 14:42:18 CST 2018 Thread-0 ==
Wed Nov 07 14:42:19 CST 2018 Thread-1 ==
Wed Nov 07 14:42:19 CST 2018 Thread-0 ==
Exception in thread "Thread-0" java.lang.OutOfMemoryError: Java heap space
    at com.example.JvmOomDemo.lambda$main$0(JvmOomDemo.java:21)
    at java.lang.Thread.run(Thread.java:748)
Wed Nov 07 14:42:20 CST 2018 Thread-1 ==
Wed Nov 07 14:42:21 CST 2018 Thread-1 ==
Wed Nov 07 14:42:22 CST 2018 Thread-1 ==

可以看到，当 Thread-0 因为持续新增 byte[] 导致堆空间耗尽后，它抛出了 OutOfMemoryError: Java heap space。而 Thread-1 仍在继续打印时间，进程并未整体退出。

四、为什么线程一 OOM 后，线程二还能继续运行

结合上述示例，可以从以下几个层面理解：

1. 异常只影响当前线程的代码路径

OOM 发生在 Thread-0 执行 new byte[1024 * 1024] 这一行。当 JVM 无法满足该次分配时，异常被抛出，Thread-0 的执行流程中断。除非这个异常被更上层捕获并继续循环，否则该线程会终止。但它不会主动通知其他线程终止。

Thread-1 并未参与大数组分配，也没有依赖 Thread-0 的内部状态，因此它的指令执行、方法调用和对象分配都不受影响。

2. 对象引用被线程栈隔离

在示例中，Thread-0 的局部变量 list 持有之前所有已分配的 byte[] 的引用。当线程因未捕获 OOM 退出时，它的线程栈被销毁，局部变量 list 不再被任何活跃对象引用。于是这些 byte[] 变成垃圾，JVM 可以回收它们。

这说明一个非常关键的行为：一个线程由于 OOM 失败后，其占用的内存可能很快被释放，从而为其他线程的运行腾出堆空间。 这也解释了为什么后续 Thread-1 还能继续正常打印日志。

3. 未捕获 OOM 不等于 JVM 进程崩溃

当线程中的异常未被捕获时，JVM 会调用该线程的 UncaughtExceptionHandler。如果没有自定义处理器，默认实现会打印异常堆栈，并结束该线程，而不是直接停止整个 JVM。

只有所有非守护线程都退出，JVM 进程才会结束。示例中 Thread-1 仍为活跃的非守护线程，所以进程继续存活。

五、如果 OOM 被 catch 吞掉会怎样

在某些代码中，开发者可能使用 try-catch 捕获了 OutOfMemoryError，但未做任何处理，例如：

try {
    byte[] data = new byte[1024 * 1024 * 100];
} catch (OutOfMemoryError e) {
    log.error("OOM caught", e);
    // 吞掉异常，继续执行
}

这种做法可以让当前线程不退出，但存在较大隐患：

• 如果 OOM 是由于堆空间被大量对象占满，且这些对象仍然被引用，那么后续任何内存分配都可能继续失败；
• 如果 OOM 发生在某些关键状态更新或事务执行过程中，吞掉异常可能导致业务数据不一致；
• catch 后继续循环申请内存，可能造成频繁 GC 和 CPU 飙高，最终影响整个服务。

因此，虽然 OOM 可被捕获，但生产环境通常不建议盲目吞掉异常，而应当结合监控、告警和降级策略处理。

六、不同 OOM 类型对进程的影响不同

题目中的“OOM”不是单一场景，Java 常见的 OOM 类型包括：

• Java heap space：堆空间不足，最常见；
• GC overhead limit exceeded：GC 花费时间占比过高，但回收效果很差；
• Permgen space 或 Metaspace：永久代或元空间不足；
• Unable to create new native thread：无法再创建本地线程，通常与操作系统线程数限制有关。

其中，堆空间类 OOM 发生后，如果触发异常的线程能够被终止，相关对象可以被回收，那么进程继续运行的可行性较高。

但如果是 Unable to create new native thread，通常意味着操作系统层面的线程资源已经接近耗尽。此时即便 Java 进程仍在，系统也可能表现为无法创建新线程、部分线程挂起或整个系统响应变慢。这种情况下的“还能运行”可能只是表象，实际服务能力已经严重受限。

七、能否继续运行，取决于四个因素

综合来看，Java 进程在发生堆内 OOM 后是否还能稳定运行，取决于：

1. 异常发生在哪个线程
   如果是核心业务线程，可能直接影响关键功能；如果是旁路任务线程，对整体服务的冲击较小。

2. 异常是否被捕获以及如何处理
   及时退出异常路径、释放引用、做好资源清理，能提高继续运行的成功率。

3. 触发 OOM 的对象是否仍然可达
   如果导致 OOM 的对象随着线程退出成为垃圾，则堆内存可被回收，JVM 可通过 GC 恢复正常分配。

4. 是否发生内存泄漏的累积效应
   如果堆中存在长期存活的泄漏对象，即使当前线程释放了部分内存，后续仍可能再次 OOM。

八、实践建议

在生产环境中，不建议将“进程没有崩溃”等同于“系统仍然健康”。一旦出现 OOM，应结合堆转储、GC 日志和监控数据定位根因，而不是依赖进程继续运行来掩盖问题。

可行的处理思路包括：

• 配置合理的 JVM 堆内存与 GC 策略；
• 对可能产生大对象的代码路径做容量评估；
• 使用监控告警及时发现 OOM 并采集现场快照；
• 对线程池、本地缓存、文件流等资源做上限控制和释放管理；
• 针对不同业务模块设置隔离线程池，降低单点 OOM 对整体服务的影响。

从技术原理上看，OutOfMemoryError 虽然严重，但它在 Java 中更像一次“分配失败”信号，而非不可逆的进程终止命令。理解这一点，有助于开发者更准确地设计异常处理策略，也能避免被“还能运行”的假象掩盖潜在的内存风险。