一、先给结论

一道流传甚广的面试题这样问：“一个线程发生OOM后，其他线程还能运行吗？”很多人凭直觉回答“不能”，理由是“内存都溢出了，程序肯定挂了”。这个答案恰恰暴露了对JVM内存模型与错误传播机制的误解。

结论先行：在绝大多数场景下，单个线程发生堆内存溢出（OutOfMemoryError: Java heap space）后，该线程本身会终止，但JVM进程不会退出，其他线程仍可正常运行。不过，“还能运行”并不等于“运行得健康”，不同类型的OOM影响范围差异很大，后文逐一展开。

二、OOM究竟是谁抛出的：理解错误的传播路径

要回答这个问题，关键在于理解两点：内存分配发生在哪里，以及错误抛给谁。

1. 分配是“线程级”的行为。 Java中每创建一个对象，都是由“当前正在执行分配语句的那条线程”完成的。以常见的JVM实现为例，新生代分配通常先在线程私有的TLAB（Thread Local Allocation Buffer）中进行；TLAB空间不足时，退回到Eden区的共享分配，必要时触发GC；若经过多轮GC、堆扩容尝试后仍无法满足本次分配，才会在“这条线程”的调用栈上抛出OutOfMemoryError。

2. 错误沿调用栈向上传播，作用域局限于当前线程。 OutOfMemoryError继承自Error，属于VirtualMachineError的子类，它和NullPointerException一样，都是沿当前线程的调用栈逐帧向上传播。如果没有任何捕获逻辑，线程会以非正常状态终止，但JVM本身并不会因此崩溃。

3. 线程死亡反而“腾出”了内存。 发生OOM的线程终止后，其栈帧中的局部变量引用随之消失，这些引用指向的对象变成不可达状态，成为GC的回收目标。也就是说，压垮它的那批对象，会在它死后被逐步回收，堆内存得以恢复，这为其他线程继续分配对象创造了条件。

4. JVM进程的存亡只看“非守护线程”。 JVM退出的条件是“不存在存活的非守护线程”，而不是“发生过OOM”。因此即便main线程OOM退出了，只要还有非守护线程在运行，进程就依然活着；反之，如果所有剩余线程都是守护线程，进程则会退出。

三、不同类型的OOM，影响范围并不相同

题目中只说“发生OOM”，但OOM是一个家族，不同成员的破坏力差别很大。

1. 堆溢出：影响最“局部”的一种。 溢出发生在申请内存的那条线程上，其他线程当前不受影响。但要注意：如果溢出的根因是某个全局性的内存泄漏（如静态集合无限增长），那么其他线程虽然此刻能运行，稍后分配较大对象时同样可能触发OOM。

2. 元空间/永久代溢出：影响的是“类加载”。 此类OOM通常由动态生成类（反射代理、字节码增强等）且未释放导致。溢出后进程仍在运行，但所有需要加载新类的操作都会失败，依赖动态代理的功能会批量报错，故障表现具有隐蔽性和迟滞性。

3. 无法创建本地线程：影响所有“想要新建线程”的代码。 已有线程可以继续运行，但任何创建新线程或扩容线程池的动作都会失败。如果应用采用“每请求一线程”模型，服务实际上已经不可用。这类问题除了与-Xss线程栈大小有关，还与操作系统层面的线程数上限、内存余量密切相关。

4. 直接内存溢出：抛给申请堆外内存的线程。 已分配的堆外缓冲区仍可使用，进程不退出，但依赖堆外内存的组件（如网络通信的缓冲区）在需要扩容时会失败。

5. GC overhead limit exceeded：最危险的一种。 它表示GC反复运行却几乎回收不到空间，进程虽然“活着”，但CPU几乎全部被GC占用，所有线程都慢如蜗牛，服务实质上已不可用。“还能运行”在这里只剩理论意义。

四、代码实验：一个线程OOM，其他线程照常运行

下面用一个最小可复现实验验证结论，使用较小的堆上限（如 -Xmx32m）运行：

import java.util.ArrayList;
import java.util.List;
public class OomSurviveDemo {
    public static void main(String[] args) {
        // 线程A：持续申请 1MB 大对象，最终触发堆溢出
        Thread oomThread = new Thread(() -> {
            List<byte[]> holder = new ArrayList<>();
            while (true) {
                holder.add(new byte[1024 * 1024]);
            }
        }, "oom-thread");
        oomThread.setUncaughtExceptionHandler((t, e) ->
                System.out.println(t.getName() + " 异常退出: " + e.getMessage()));
        // 线程B：模拟正常业务，验证其是否受影响
        Thread bizThread = new Thread(() -> {
            while (true) {
                System.out.println("业务线程仍在运行: " + System.nanoTime());
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                    return;
                }
            }
        }, "biz-thread");
        oomThread.start();
        bizThread.start();
    }
}

运行结果符合预期：oom-thread抛出”Java heap space”后终止，而biz-thread每秒照常打印，进程持续存活。进一步可以把bizThread设置为守护线程做对照实验：当业务线程全部退出、只剩守护线程时，即使没有新的OOM，进程也会随之结束——这再次印证了JVM的退出条件与OOM无关。

五、“还能运行”背后的隐患：不能盲目乐观

结论虽然是“还能运行”，但生产环境中绝不能因此掉以轻心。

1. 共享状态可能已被破坏。 如果OOM发生在修改共享数据结构的半途（例如正在向共享集合写入），该结构可能处于不一致状态，后续读到脏数据或触发更隐蔽的错误。OOM虽然是“内存问题”，但它的副作用可能污染业务数据。

2. 显式锁可能无法释放。 线程死亡时，synchronized持有的内置锁会随线程终止自动释放；但通过显式锁获取的锁不会自动释放。如果代码在加锁与解锁之间抛出OOM且没有finally保护，其他等待该锁的线程将永久阻塞。因此锁的释放必须放在finally中。

3. 线程池可以“自愈”，但任务会丢失。 工作线程执行任务时抛出Error会终止，线程池随后会补充新的工作线程，池本身不会消失。但代价是：出错任务的结果丢失，且若缺少统一的异常捕获，故障可能无任何日志可查。建议对所有提交的任务做包装，在捕获Throwable后记录上下文并执行降级逻辑。

4. 泄漏未根除，OOM必将复发。 如果溢出根因是全局泄漏，单条线程死掉只是“暂时止血”。随着业务继续运行，内存会再次耗尽，最终表现为“周期性OOM”，直到进程被重启或彻底崩溃。

六、工程实践建议

1. 提前布置“案发现场”。 在启动参数中加入 -XX:+HeapDumpOnOutOfMemoryError 与 -XX:HeapDumpPath，让JVM在OOM发生时自动生成堆转储文件，再借助通用的内存分析工具查看支配树与引用链，定位泄漏源头。

2. 建立可观测性。 将堆使用率、各分代内存、GC频率与耗时、线程数、直接内存等指标接入监控告警服务，在内存爬坡阶段就介入处理，而不是等到OOM才被动响应；日志层面重点检索OutOfMemoryError关键字，并关联发生时的线程与业务上下文。

3. 线程池兜底与业务隔离。 核心业务使用独立线程池，避免相互拖累；统一包装任务捕获Throwable，保证“线程死、数据在、日志全”；对可降级的操作准备兜底逻辑。

4. 快速失败优先。 除极少数确有把握的场景外，不建议捕获OOM后继续提供服务——进程状态已不可信，更稳妥的做法是记录现场后快速失败，由容器平台的健康检查与重启策略将服务拉起，恢复到确定性的初始状态。

5. 容量与参数治理。 合理设置堆上限与线程栈大小，评估操作系统层面的线程数与句柄限制；对大集合、大查询、缓存设置容量上限与淘汰策略，从源头减少分配失败的概率。

七、总结

回到最初的问题：“一个线程OOM后，其他线程还能运行吗？”——能。因为内存分配失败是发生在单条线程调用栈上的局部事件，错误只沿该线程传播，线程死亡后其持有的对象会被GC回收，而JVM的存亡仅取决于是否还有非守护线程。但工程上必须记住两点：其一，OOM类型不同，影响范围不同，“无法创建本地线程”“GC overhead”等情况会让整个服务实质不可用；其二，“还能运行”不等于“运行得正确”，共享状态损坏、锁泄漏、任务丢失与复发风险，都要求我们以“快速失败＋现场留存＋根因治理”的态度对待每一次OOM。