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

“一个线程发生 OOM 之后，其他线程还能不能继续运行？”——这是一道流传很广的面试题，也是一个容易被简单化回答的问题。很多人第一反应是“OOM 了进程肯定挂”，也有人认为“只要捕获了异常就没事”。这两种回答都不够准确。OOM 并不是一个简单的“是与否”问题，它涉及 JVM 内存区域划分、对象作用域、垃圾回收机制、线程调度以及异常传播路径等多个知识点。本文以堆内存溢出为切入点，结合可复现的示例代码和运行现象，把这个问题讲清楚。

一、先厘清概念：OOM 不止一种

java.lang.OutOfMemoryError 是一个异常类，但它背后对应着多种不同的内存区域与触发原因，常见的有：

• 堆溢出：java.lang.OutOfMemoryError: Java heap space，对象分配速度超过堆容量且 GC 无法回收足够空间；
• 元空间/永久代溢出：类元数据过多，无法继续加载类；
• 无法创建本地线程：java.lang.OutOfMemoryError: unable to create new native thread，线程栈与本地内存耗尽；
• 直接内存溢出：堆外内存分配失败；
• GC 开销超限：GC 时间占比过高而回收效果极差。

不同区域的 OOM，对应用的影响范围差别很大。本文聚焦最常见的堆内存溢出，讨论它对线程运行状态的影响。

二、结论先行：堆溢出后，其他线程通常仍可运行

直接给出结论：当某个线程因堆内存不足抛出 OutOfMemoryError 时，只要该异常被该线程捕获或该线程终止，JVM 进程本身并不会立即退出，其他线程仍然可以被调度执行。

原因在于：堆溢出影响的是“对象分配”这一能力，而不是“整个进程”的存续。JVM 并没有规定 OOM 必须导致进程终止——它只是抛出一个 Error 类型的异常。如果这个异常在某个线程的调用栈中被捕获并处理，该线程可以继续存活；如果未被捕获，该线程会终止，但 JVM 中其他非守护线程仍会继续运行。

需要强调两点边界条件：

1. 该结论针对堆溢出。如果是“无法创建本地线程”这类 OOM，说明线程资源已耗尽，新线程无法启动，影响面更广；
2. “还能运行”不等于“运行正常”。发生堆溢出后，应用通常处于高风险降级状态：GC 频繁、响应变慢、后续分配随时可能再次失败。

三、可复现的示例：一个线程疯狂分配，另一个线程持续打印

下面的示例刻意构造了两个线程：线程 A 在循环中不断向集合中添加字节数组，制造堆压力；线程 B 只做周期性打印，观察它是否还能继续运行。

public class HeapOomDemo {
    public static void main(String[] args) {
        // 线程 A：持续分配内存，制造堆溢出
        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();
                }
            }
        }).start();
        // 线程 B：仅做周期性打印，用于观察存活情况
        new Thread(() -> {
            while (true) {
                System.out.println(new Date() + " " + Thread.currentThread() + " alive");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }
}

在堆容量有限的运行参数下（例如通过 -Xmx 限制最大堆），程序运行一段时间后会在线程 A 中看到类似如下的异常：

Exception in thread "Thread-0" java.lang.OutOfMemoryError: Java heap space
    at HeapOomDemo.lambda$main$0(HeapOomDemo.java:xx)
    at java.lang.Thread.run(Thread.java:xxx)

而与此同时，线程 B 的打印输出仍在持续出现。这直观说明：线程 A 因 OOM 终止，线程 B 依然在运行，进程并未退出。

四、为什么会出现这个现象？从三个层面理解

1. 异常传播层面：OOM 是 Error，不是进程终止信号

OutOfMemoryError 继承自 Error，和普通异常一样遵循“沿调用栈向上传播”的规则。若线程 A 的 run 方法没有捕获它，异常会到达线程顶层，导致该线程终止。但 JVM 并不会因为一个线程的未捕获异常而关闭整个进程——只要还有其他非守护线程存活，进程就继续存在。

2. 内存分配层面：失败是“本次分配失败”

堆溢出意味着“这一次对象分配请求无法满足”，而不是“堆内存被永久锁死”。触发 OOM 后，垃圾回收器仍会继续工作。如果后续有对象变为不可达，内存会被回收，新的分配请求又可能成功。因此，其他线程若分配量小、或者触发了有效回收，仍可能继续申请到内存。

3. 线程调度层面：线程之间相互独立

JVM 中每个线程有独立的调用栈和程序计数器，堆是共享的，但线程的调度与存活状态互不直接绑定。一个线程终止，不会自动终止其他线程。这正是示例中线程 B 能继续打印的根本原因。

五、示例能说明问题，但不能过度推广

上述结论成立，但必须提醒几个容易被忽略的风险点：

• 不可控的连锁失败：堆溢出后，其他线程的任何一次对象分配都可能再次触发 OOM。示例中线程 B 只做打印，分配压力小，所以看起来“稳定”；真实业务线程若继续创建对象，可能接连失败。
• 异常被吞掉的隐患：如果代码用 catch (Throwable t) 捕获了 OOM 却不做任何处理，线程会带着不完整的状态继续运行，可能产生数据不一致，比直接终止更危险。
• GC 风暴：堆接近耗尽时，GC 会频繁触发且回收效果差，CPU 大量时间耗在 GC 上，表现为应用整体卡顿甚至假死，即便线程“还在运行”也已失去服务能力。
• 守护线程差异：若存活线程全是守护线程，进程会在非守护线程结束后退出，观察结果会不同。

六、生产环境中的正确应对策略

理解原理之后，更重要的是落地防护。建议从以下方面着手：

1. 合理设置堆参数与容量规划：根据业务对象生命周期和峰值流量设定堆大小，避免“刚好够用”的临界配置。
2. 避免无界集合累积：示例中的 List 无限添加是典型的泄漏模式。生产代码应使用有界队列、设置缓存上限，或引入弱引用/软引用控制对象生命周期。
3. 完善监控与告警：对堆使用率、GC 频率与耗时、OOM 次数建立监控指标，配置阈值告警，尽早发现内存增长趋势而非等到溢出。
4. 配置自动故障处置：可通过 JVM 参数在堆溢出时输出堆转储文件，便于事后定位；结合容器编排的重启策略实现故障自愈。
5. 谨慎捕获 Error：不要随意 catch (Throwable) 后继续执行业务逻辑。对 OOM 应记录日志、释放资源并让当前任务失败，由上层决定降级或重启。
6. 压测与容量验证：在上线前通过压力测试验证内存水位，确认在峰值负载下仍有安全余量。

七、小结

回到最初的问题：一个线程发生堆内存溢出后，其他线程还能运行吗？ 答案是：通常还能运行，但整个应用已进入高风险状态。 OOM 是某个线程某次内存分配的失败，不等于进程立即死亡；线程之间相互独立，未捕获的 Error 只终止当前线程。但真正值得关注的不是“还能不能跑”，而是“跑得是否健康、是否可观测、是否可恢复”。把 OOM 当作一次需要被监控、被定位、被防护的故障信号，才是工程实践中更负责任的态度。