Java 线程池 close 怎么收尾：shutdown、awaitTermination 与未完成任务核对

写Java多线程逻辑时大家几乎都绕不开ExecutorService线程池，用完直接强关很容易丢正在跑的任务，直接硬等又不知道什么时候能跑完，标准的收尾流程要分几步走：先用shutdown停止接收新提交的任务，再用awaitTermination阻塞等待已入队的任务全部执行完，最后校验一遍剩下未完成的任务做兜底处理，就能把线程池资源稳妥释放，不会出现资源泄漏、进程挂着退不出的问题。

调用shutdown之后线程池就不会再接收新任务，等队列里所有提交过的任务跑完才会进入终止状态；搭配awaitTermination可以设置最大等待时长，超时没跑完的任务可以调用shutdownNow尝试打断执行线程，最后再核对返回的未完成任务列表做日志落盘或重试兜底，就是一套生产环境可用的线程池关闭逻辑。

线上服务准备停止时，线程池最怕的不是“关不掉”，而是调用方以为已经关干净，队列里却还有任务，或者等待超时后没有留下任何可核对的结果。Java 的 ExecutorService 可以用 shutdown() 停止接收新任务，再用 awaitTermination() 等待已提交任务完成；实现了 AutoCloseable 的 JDK 版本还可以调用 close() 做阻塞式收尾。真正可靠的流程要把正常完成、超时和中断分开记录。

先把线程池收尾动作定成三段

调用方通常只需要一个清晰契约：第一步不再接收新任务，第二步给队列中的工作一个完成窗口，第三步对超时或中断做明确的兜底。不要一上来就用 shutdownNow()，它会尝试中断正在执行的任务，并返回尚未开始的任务列表；这更像强制停止，而不是默认关闭流程。

static boolean stopGracefully(ExecutorService pool, Duration wait) {
    pool.shutdown();
    try {
        if (pool.awaitTermination(wait.toMillis(), TimeUnit.MILLISECONDS)) {
            return true;
        }
        List neverStarted = pool.shutdownNow();
        return pool.awaitTermination(5, TimeUnit.SECONDS);
    } catch (InterruptedException ex) {
        pool.shutdownNow();
        Thread.currentThread().interrupt();
        return false;
    }
}

这段最小实现有三个可观察结果：正常窗口内结束返回 true；等待窗口耗尽后进入强制兜底；当前线程被中断时恢复中断标记并返回 false。生产代码应把 neverStarted.size() 和最终状态写入日志或指标，不能只返回一个布尔值。

shutdown 和 close 的边界不一样

shutdown() 是状态切换：从调用它开始，新的 execute 或 submit 会被拒绝，但已经提交的任务仍有机会完成。它不会等待，也不会替调用方判断队列是否清空，所以适合放在停止入口。

close() 是 AutoCloseable 形式的便捷收尾。使用 try-with-resources 时，离开代码块会关闭执行器；对于普通的 ExecutorService 引用，调用者仍要确认当前 JDK 和具体实现提供的关闭语义，并把它当成“关闭并等待”的生命周期动作，而不是提交任务后的随手清理。

try (ExecutorService pool = Executors.newFixedThreadPool(4)) {
    pool.submit(() -> writeOrderEvent());
    pool.submit(() -> refreshSearchIndex());
} // 离开作用域时进入关闭流程

如果业务要求“最多等 30 秒，超时就报警并停止”，显式写出 shutdown 与 awaitTermination 更容易测试，也能在超时分支保留未开始任务数量。不要把 close() 当成对所有任务都能成功完成的保证。

等待时要区分完成、超时和中断

awaitTermination 返回 true 表示执行器已经终止，返回 false 表示等待时间到了但它还没有终止。两者都不是异常。真正需要特别处理的是 InterruptedException：它说明等待线程收到中断请求，捕获后应先发出停止信号，再调用 Thread.currentThread().interrupt() 把标记还回去。

• 正常完成：记录耗时和队列剩余为零，允许进程继续退出。
• 超时：调用 shutdownNow()，记录返回的未启动任务，继续等待一个短窗口。
• 中断：停止等待但保留中断状态，把“收尾未完成”交给上层退出策略。

这里别急着把超时都归为线程池故障。任务可能正在等待外部 I/O，也可能是任务自身忽略了中断。收尾日志至少要包含线程池名称、首次关闭时间、等待上限、未启动任务数和最终 isTerminated() 结果。

一个可测试的结果核对示例

为了验证收尾逻辑，可以提交一个短任务和一个可中断任务，再给很短的等待窗口。测试关注的是状态变化，而不是猜测线程何时结束：

ExecutorService pool = Executors.newFixedThreadPool(2);
CountDownLatch started = new CountDownLatch(1);
Future> job = pool.submit(() -> {
    started.countDown();
    try {
        Thread.sleep(Duration.ofSeconds(30).toMillis());
    } catch (InterruptedException ex) {
        Thread.currentThread().interrupt();
    }
});

started.await();
pool.shutdown();
boolean finished = pool.awaitTermination(100, TimeUnit.MILLISECONDS);
if (!finished) {
    List pending = pool.shutdownNow();
    boolean stopped = pool.awaitTermination(1, TimeUnit.SECONDS);
    System.out.println("pending=" + pending.size() + ", terminated=" + stopped);
}

可见的成功状态是：首次等待返回 false，强制收尾后最终等待返回 true，任务线程打印或记录到中断路径。若最终仍未终止，不应把进程退出当成正常完成；应继续追踪任务是否阻塞在不可中断的外部调用。

常见误区和最终建议

最常见的错误是只调用 shutdown() 就认为线程池已经结束，只调用 shutdownNow() 就认为所有任务都停止，或者捕获中断后没有恢复中断标记。另一个隐蔽问题是关闭入口和提交入口并发：提交方必须先收到服务停止信号，再由统一生命周期组件关闭线程池，否则仍会出现偶发的 RejectedExecutionException。

把正常窗口、强制兜底和中断结果分别暴露出来，线程池关闭才真正可运维。对于短生命周期的批处理程序，可以直接采用 try-with-resources；对于长期运行的 Web 服务，建议显式关闭并把等待结果、未启动任务和终止状态接入退出日志。

常见问题：线程池关闭时怎么判断真的结束

调用 shutdown 后还能提交任务吗？

不能把它当成可继续提交的状态。新的提交会被拒绝，已经提交的任务仍按正常策略执行。

awaitTermination 返回 false 要立刻强制停止吗？

先确认等待窗口是否合理，以及任务是否卡在外部 I/O。若进程必须退出，再调用 shutdownNow()，同时保留返回列表和最终 isTerminated() 结果。

为什么捕获 InterruptedException 后还要恢复标记？

因为捕获异常会清除当前线程的中断标记。恢复它，上一层生命周期管理代码才有机会继续做正确的退出决策。