Java ExecutorService close 怎样等待任务收尾

我以前给线程池收尾时，最容易把 shutdown() 和“所有任务已经结束”当成一件事。它们其实是两个动作：shutdown() 只负责拒绝新任务，不会等待旧任务跑完；Java 19 以后，ExecutorService 还可以直接调用 close()，它会做有序关闭并一直等到执行器终止。

官方地址：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/concurrent/ExecutorService.html

如果目标是“离开作用域时，已经提交的任务先完成再释放线程池”，优先考虑 try (ExecutorService pool = ...)。如果需要等待上限、超时后升级为强制停止，就使用 shutdown()、awaitTermination() 和 shutdownNow() 的组合。

close 为什么会等任务收尾

ExecutorService 现在继承了 AutoCloseable。它的默认 close() 先触发有序关闭，再等待已经提交的任务执行完并让执行器终止。因此，try-with-resources 的右大括号不是“发出关闭通知就返回”，而是关闭动作完成后才离开作用域。

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;

ExecutorService pool = Executors.newFixedThreadPool(2);
try (pool) {
    pool.submit(() -> {
        // 模拟一个必须完成的收尾任务
        try {
            TimeUnit.MILLISECONDS.sleep(300);
        } catch (InterruptedException ex) {
            // 收到中断时恢复标记，让上层仍能感知取消
            Thread.currentThread().interrupt();
        }
    });
    // 退出 try 时，close 会等待已提交任务完成
}
System.out.println("线程池已经收尾");

这里没有调用 Future.get()，但 close() 仍会等待任务结束。若任务本身的返回值或异常必须被业务处理，仍要保存 Future 并调用 get()；关闭等待和读取任务结果是两件事。

shutdown 和 awaitTermination 分别负责什么

shutdown() 返回后，线程池可能还有任务在执行。要等待它真正终止，需要在关闭请求之后调用 awaitTermination(timeout, unit)。它返回 true 表示已终止，返回 false 表示等待时间耗尽。

ExecutorService pool = Executors.newFixedThreadPool(2);
try {
    // 先提交业务任务，再禁止新的任务进入
    pool.submit(() -> doWork());
} finally {
    pool.shutdown();
    try {
        // 给已有任务一个明确的优雅收尾窗口
        if (!pool.awaitTermination(5, TimeUnit.SECONDS)) {
            System.out.println("等待窗口已耗尽");
        }
    } catch (InterruptedException ex) {
        // 当前线程被打断时，交给下面的中断处理分支
        Thread.currentThread().interrupt();
    }
}

这套写法适合调用方必须掌控等待上限的场景。需要注意：awaitTermination() 只是等待，它不会自动取消超时任务；是否升级为 shutdownNow() 要由业务决定。

超时后怎样处理强制关闭

shutdownNow() 的语义是尽力停止正在执行的任务、让等待队列中的任务不再启动，并返回尚未开始的任务列表。它不会保证正在运行的任务立刻消失，任务只有在正确响应中断时才容易结束。

pool.shutdown();
try {
    // 先给已经提交的任务一次正常收尾机会
    if (!pool.awaitTermination(5, TimeUnit.SECONDS)) {
        pool.shutdownNow();
        // 强制停止后仍要等待执行器进入终止状态
        if (!pool.awaitTermination(5, TimeUnit.SECONDS)) {
            System.err.println("线程池仍未终止");
        }
    }
} catch (InterruptedException ex) {
    // 当前线程被打断时，也尽力停止线程池中的任务
    pool.shutdownNow();
    // 不吞掉调用方的中断信号
    Thread.currentThread().interrupt();
}

对可取消任务来说，代码内部还应该在循环或阻塞点检查中断，并用 finally 释放文件、连接等资源。不要把“调用了 shutdownNow()”写成“任务已经取消”的确定结论。

实际项目怎样选择

• 作用域结束前必须等已提交任务完成，且不需要自定义超时：用 try-with-resources 管理 ExecutorService，让 close() 统一收尾。
• 服务停机需要最大等待时间：先 shutdown()，再 awaitTermination()，超时后按任务可取消性决定是否 shutdownNow()。
• 必须拿到每个任务的返回值或异常：保存 Future，单独处理 get()；不要只依赖线程池已经终止这一事实。
• 捕获 InterruptedException 后不要静默吞掉中断，通常应执行必要清理并恢复 interrupt status。

我现在会先问“收尾是否必须完成”和“等待是否有上限”这两个问题，再决定 API。close() 解决的是资源作用域的完整退出；shutdown() 加 awaitTermination() 解决的是可观测、可升级的停机策略。

常见问题

close 和 shutdown 有什么区别？

shutdown() 只发起有序关闭并立即返回；close() 会发起同样的有序关闭，并等待任务完成、执行器终止。

shutdownNow 会等待任务真正结束吗？

不会。它只是尽力停止，并返回尚未开始的任务；如需确认终止状态，仍要调用 awaitTermination()。

close 被中断后会怎样？

官方默认实现会按强制关闭处理，继续等待正在执行的任务完成，并在返回前恢复当前线程的中断状态。