Java 堆内存溢出后，其他线程还能运行吗？

在 Java 面试与线上故障排查中，有一个常被讨论的问题：“一个线程发生 OOM 后，其他线程还能运行吗？”很多回答习惯性地给出“能”或“不能”的二选一结论，但这道题真正的难点在于：OOM 并不是单一错误，而是多种资源耗尽场景的统称，不同 OOM 类型对 JVM 进程的影响路径完全不同。

本文聚焦最常见的 Java 堆内存溢出（java.lang.OutOfMemoryError: Java heap space），分析它发生后，进程内其他线程是否仍可继续调度与执行。

一、先给结论

对于堆内存溢出，答案是：在多数情况下，其他线程还能继续运行一段时间。

但这句话有三个重要前提：

1. 触发 OOM 的线程本身抛出的是 OutOfMemoryError，而不是直接导致进程崩溃；
2. JVM 没有因为频繁 Full GC 而进入“GC overhead limit exceeded”等连锁状态；
3. 操作系统层面没有因为内存耗尽而触发 OOM Killer 杀死 Java 进程。

也就是说，“还能运行”不等于“仍然健康”。理解这一点，比记住结论更重要。

二、为什么堆溢出后其他线程还可能运行？

1. 线程与堆的关系不是“一对一绑定”

JVM 运行时数据区中，堆是所有线程共享的区域，而虚拟机栈、本地方法栈、程序计数器是线程私有的。一个线程在堆上分配对象失败，并不等于其他线程的栈帧、局部变量和调度状态立即失效。

当某个线程请求分配对象时，如果堆空间不足，JVM 会先尝试触发垃圾回收。若回收后仍无法满足分配需求，JVM 才抛出 OutOfMemoryError。这个异常首先影响的是发起分配动作的那个线程。

2. 异常作用域通常限于当前线程

OutOfMemoryError 继承自 Error，属于 Throwable 体系。如果代码没有捕获它，异常会沿着当前线程的调用栈向上传播，最终导致该线程终止。但线程终止不等于 JVM 终止。

只要进程中还有非守护线程存活，JVM 就不会退出。其他线程如果不需要继续申请大量堆内存，仍可继续执行打印日志、响应请求、处理已有数据等操作。

3. GC 仍在工作，但空间可能反复紧张

堆溢出后，垃圾回收器并不会立刻停止工作。它会继续尝试回收不可达对象。如果其他线程能够释放部分对象引用，堆空间可能短暂恢复，其他线程就能继续分配少量对象。

问题在于，这种恢复往往不稳定：一旦存活对象接近堆上限，GC 会变得频繁，应用吞吐量急剧下降。

三、用代码验证：一个线程堆溢出，另一个线程继续打印

下面用一个最小示例观察现象。示例中两个线程同时启动：

• 线程一：持续向集合中添加字节数组，快速消耗堆空间；
• 线程二：每秒打印一次当前时间和线程信息。

import java.util.ArrayList;
import java.util.Date;
import java.util.List;
public class HeapOomThreadDemo {
    public static void main(String[] args) {
        // 线程一：不断分配对象，模拟堆内存溢出
        new Thread(() -> {
            List<byte[]> list = new ArrayList<>();
            while (true) {
                System.out.println(new Date() + " " + Thread.currentThread() + " allocating");
                byte[] b = new byte[1024 * 1024]; // 每次约 1MB
                list.add(b);
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }, "oom-thread").start();
        // 线程二：只做轻量打印，观察是否继续运行
        new Thread(() -> {
            while (true) {
                System.out.println(new Date() + " " + Thread.currentThread() + " alive");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }, "alive-thread").start();
    }
}

在堆上限较小的环境下运行，通常会看到：

1. oom-thread 先抛出 java.lang.OutOfMemoryError: Java heap space 并终止；
2. alive-thread 仍可能继续输出若干次日志；
3. 若堆压力持续增大或 GC 占用过高，整个进程最终也可能失去响应。

这个现象说明：OOM 的直接影响对象是触发分配的线程，而不是整个 JVM 的所有线程。

四、哪些情况下“其他线程还能运行”会失效？

1. 触发的是“GC overhead limit exceeded”

当 JVM 发现 GC 花费了大量时间，却只回收了极少内存时，会抛出：

java.lang.OutOfMemoryError: GC overhead limit exceeded

这时应用几乎把 CPU 时间都耗在 GC 上，其他线程即使逻辑上可运行，也会因为调度和内存分配受阻而接近“假死”。

2. 触发的是元空间或永久代溢出

如果 OOM 发生在元空间（Metaspace）或永久代（PermGen），通常与类加载器泄漏、动态生成类过多有关。这类问题可能导致类加载失败，进而影响依赖新类加载的线程。

3. 触发的是“Unable to create new native thread”

这类错误表示操作系统无法创建更多原生线程。它往往与线程数上限、栈内存总量有关，而不是堆空间本身。此时新线程无法启动，已有线程可能仍短暂运行，但整体服务能力已经受损。

4. JVM 进程被操作系统杀死

如果 Java 进程占用内存过大，触发操作系统层面的 OOM Killer，那么整个进程会被强制结束，所有线程自然都不再运行。这已经不属于 JVM 内部异常处理范畴。

五、工程实践中的正确应对方式

1. 不要依赖“其他线程还能跑”来兜底

堆溢出后，虽然其他线程可能短暂存活，但应用通常已处于不可靠状态。继续对外提供服务，可能出现：

• 请求处理超时；
• 数据写入不完整；
• 缓存与数据库状态不一致；
• 监控指标剧烈抖动。

更合理的做法是：快速失败、保留现场、触发告警、必要时重启。

2. 配置合理的堆大小与 GC 策略

根据业务峰值内存需求设置堆上限，并选择合适的垃圾回收器。同时开启 GC 日志，便于事后分析对象分配速率、晋升速度和 Full GC 频率。

3. 捕获 OOM 并记录关键信息

可以在关键线程入口处捕获 OutOfMemoryError，记录堆转储（Heap Dump）和线程栈：

try {
    // 业务逻辑
} catch (OutOfMemoryError e) {
    // 记录日志、触发堆转储、通知监控系统
    throw e;
}

注意：捕获后不建议继续执行复杂业务逻辑，因为此时 JVM 状态已不可信。

4. 通过监控与告警提前发现问题

对堆使用率、GC 次数、GC 耗时、线程数等指标设置告警。在云环境中，可结合通用监控告警与日志服务能力，对异常模式进行集中观测。例如，在百度智能云上运行 Java 应用时，可将 JVM 指标接入监控体系，及时发现内存增长趋势。

5. 排查内存泄漏而非只调大堆

如果 OOM 反复出现，优先排查：

• 静态集合是否持续增长；
• 缓存是否缺少淘汰策略；
• 监听器、回调是否未注销；
• 线程池任务队列是否无界；
• 大对象是否被长期强引用。

单纯调大堆上限，往往只是推迟故障发生时间。

六、总结

回到问题本身：Java 堆内存溢出后，其他线程还能运行吗？

准确回答是：

• 对于普通堆空间溢出，触发 OOM 的线程通常会终止，其他线程在短期内仍可能继续运行；
• 但这种“能运行”是脆弱且不可依赖的，应用整体已处于高风险状态；
• 真正重要的不是记住“能”或“不能”，而是理解 OOM 类型、异常传播路径、GC 行为与进程存活条件之间的关系。

在工程实践中，应当把 OOM 视为严重故障信号，而不是可以忽略的局部异常。通过合理的内存规划、完善的监控告警、及时的堆转储分析和代码层面的泄漏排查，才能把问题控制在故障发生之前。