本文探讨OOM是否导致JVM退出，结论是不一定。OOM通常只杀死当前线程，若有其他非守护线程，JVM会继续运行。但在生产环境中，推荐使用JVM参数让其在OOM时快速失败并重启。

这是一个非常经典且重要的问题。

核心答案：不一定。OOM (OutOfMemoryError) 不一定会直接导致 JVM 退出。

具体情况取决于 OOM 发生的内存区域、发生在哪个线程以及是否有相应的处理机制。

让我们深入分析一下几种情况：

1. JVM 不会退出的情况

这是最常见的情况。OutOfMemoryError 本质上是一个 Error 类型的可抛出对象（Throwable），就像 Exception 一样。它是在某个特定线程的执行过程中被抛出的。

关键点：OOM 通常只“杀死”当前线程。

如果一个线程在尝试分配内存时触发了 OOM，并且这个错误没有被任何 try-catch 块捕获，那么该线程会因“未捕获的异常”而终止。

但是，如果 JVM 中还有其他非守护（non-daemon）线程正在运行，JVM 进程本身会继续运行。

典型例子：

假设你有一个 Web 服务器（如 Tomcat），它为每个请求分配一个工作线程。

1. 一个用户的请求（线程A）尝试加载一个巨大的文件到内存中，导致了 java.lang.OutOfMemoryError: Java heap space。
2. 线程A因为未捕获这个 Error 而死亡。
3. Web 服务器会记录这个错误，并向该用户返回一个 500 错误页面。
4. 但是，其他的用户请求（由线程B、线程C等处理）完全不受影响，它们可以继续正常服务，只要后续操作有足够的内存（比如GC回收了线程A占用的部分内存）。
5. 因此，服务器（JVM进程）本身并没有退出，只是处理能力暂时受到了影响。

代码示例：

public class OOMTest {
    public static void main(String[] args) {
        // 主线程启动一个会OOM的线程
        new Thread(() -> {
            try {
                System.out.println(Thread.currentThread().getName() + " 开始...");
                List<byte[]> list = new ArrayList<>();
                while (true) {
                    list.add(new byte[1 * 1024 * 1024]); // 每次分配1MB
                }
            } catch (Throwable t) {
                // 即使在这里捕获，这个线程的后续逻辑也无法执行了
                // 但关键是这个线程会在这里终止
                System.out.println(Thread.currentThread().getName() + " 捕获到了错误：" + t.getMessage());
            }
        }, "OOM-Thread").start();

        // 主线程继续运行，不受影响
        System.out.println(Thread.currentThread().getName() + " 继续执行...");
        try {
            // 持续打印，证明JVM还活着
            while (true) {
                System.out.println(Thread.currentThread().getName() + " 正在运行...");
                Thread.sleep(1000);
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

运行结果（使用 -Xmx20m 启动）：

main 继续执行...
OOM-Thread 开始...
main 正在运行...
main 正在运行...
... (多次打印)
Exception in thread "OOM-Thread" java.lang.OutOfMemoryError: Java heap space
    at OOMTest.lambda$main$0(OOMTest.java:9)
    at java.base/java.lang.Thread.run(Thread.java:834)
main 正在运行...
main 正在运行...
...

从结果可以看出，OOM-Thread 线程抛出 OOM 并死亡了，但 main 线程一直在运行，证明 JVM 进程没有退出。

2. JVM 可能会退出或变得不稳定的情况

虽然 OOM 不会“直接”让 JVM 退出，但在以下几种情况下，它会导致 JVM 事实上的崩溃或退出。

1. OOM 发生在关键线程中
   如果抛出 OOM 的线程是 main 线程，或者是应用中唯一的非守护线程，那么当这个线程死亡后，JVM 中没有其他非守护线程了，JVM 就会正常退出。

2. GC overhead limit exceeded
   这是一种特殊的 OOM。它表示 JVM 花费了超过 98% 的时间在垃圾回收（GC）上，但只回收了不到 2% 的堆内存。这意味着堆里几乎全是存活对象，GC 已经无能为力了。即使某个线程捕获了这个错误，其他线程很快也会遇到同样的问题，因为内存已经完全被占满且无法释放。此时，整个应用程序已经陷入停滞，虽然 JVM 进程还在，但已经无法提供任何服务，离崩溃只有一步之遥。

3. unable to create new native thread
   这种 OOM 表明 JVM 无法再向操作系统申请创建新的本地线程。这通常是因为进程的线程数达到了操作系统的限制，或者系统内存不足以分配给新线程的栈空间。这是一个非常严重的问题，它会影响到 JVM 的核心功能（如 GC 线程）或应用框架（如线程池），很可能导致整个应用瘫痪。

4. OOM 导致应用状态不一致
   即使 OOM 只杀死了某个工作线程，但如果这个线程在执行一个关键的、非事务性的操作（比如修改多个数据），它的突然死亡可能会导致数据状态不一致。这种不一致的状态可能会在后续引发更严重的、无法预料的错误，最终迫使整个应用无法服务。

3. 生产环境的最佳实践：让它退出（Fail-Fast）

在生产环境中，一个发生过 OOM 的 JVM 往往处于一个不健康、不稳定的“僵尸”状态。与其让它“带病运行”，不如采取“快速失败”（Fail-Fast）的策略。

为什么推荐让它退出？

• 状态不可靠：你无法保证 OOM 之后应用的内部状态还是一致的。
• 问题难排查：一个半死不活的 JVM 可能会产生各种奇怪的后续问题，增加排查难度。
• 恢复困难：即使 GC 回收了一些内存，但导致 OOM 的根本原因（如内存泄漏）依然存在，很快会再次爆发。

如何实现 Fail-Fast？
Java 提供了非常有用的 JVM 参数来处理 OOM：

• -XX:+HeapDumpOnOutOfMemoryError
  当 OOM 发生时，自动生成一个堆转储（Heap Dump）文件。这是排查内存泄漏问题的必备神器。

• -XX:HeapDumpPath=/path/to/dump.hprof
  指定堆转储文件的存放路径。

• -XX:OnOutOfMemoryError="<command>"
  当 OOM 发生时，执行一个外部命令。例如，你可以用它来发送告警或者执行重启脚本。
  -XX:OnOutOfMemoryError="sh /opt/scripts/restart.sh"

• -XX:+ExitOnOutOfMemoryError (Java 8u92+) / -XX:+CrashOnOutOfMemoryError (更高版本)
  这是一个更直接的参数，它告诉 JVM 在发生第一次 OOM 时直接退出（exit）或崩溃（crash，会生成更详细的 hs_err_pid 文件）。在容器化环境（如 Docker/Kubernetes）中，这非常有用，因为容器编排系统（如 K8s）可以检测到进程退出并自动重启一个新的、健康的实例。

总结