shutdown() 是默认首选，shutdownNow() 是紧急兜底手段；前者仅停止接收新任务并等待执行完队列任务，后者强制中断所有线程并清空队列，但中断是否生效取决于任务是否响应中断。
shutdown() 和 shutdownNow() 到底该用哪个？
直接说结论：shutdown() 是默认首选，shutdownNow() 是紧急兜底手段——不是“更狠”，而是“更危险”。很多线上问题就源于把 shutdownNow() 当成“快速关闭”来滥用。
关键区别不在名字，而在行为契约：
-
shutdown()：只改状态（RUNNING → SHUTDOWN），不中断任何线程，队列任务照常执行，适合数据写入、日志落盘等必须完成的场景 -
shutdownNow()：强行发Thread.interrupt()给所有工作线程，并清空队列，返回未执行的Runnable列表；但**中断是否生效，完全取决于任务代码是否响应中断**（比如没捕获InterruptedException或没轮询Thread.currentThread().isInterrupted()）
为什么调了 shutdown() 后程序还不退出？
这是最常被卡住的问题：你写了 threadPool.shutdown()，main 线程却直接结束了，后台线程还在跑，JVM 拒绝退出——因为线程池里的 Worker 线程默认是非守护线程（daemon=false）。
正确姿势必须配对使用：awaitTermination()
立即学习“Java免费学习笔记（深入）”；
- 它不会自动等待，只是阻塞当前线程，轮询判断线程池是否进入
TERMINATED状态 - 必须设超时（比如 30 秒），否则可能永久挂起
- 超时后若未终止，再决定是否 fallback 到
shutdownNow()
示例片段：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
threadPool.shutdown();
try {
if (!threadPool.awaitTermination(30, TimeUnit.SECONDS)) {
threadPool.shutdownNow();
if (!threadPool.awaitTermination(5, TimeUnit.SECONDS)) {
System.err.println("线程池强制关闭失败");
}
}
} catch (InterruptedException e) {
threadPool.shutdownNow();
Thread.currentThread().interrupt();
}
interruptIdleWorkers() 干了什么？为什么 shutdown 不杀正在跑的任务？
shutdown() 内部调用的 interruptIdleWorkers() 只中断「空闲线程」——即正阻塞在 workQueue.take() 上、手里没活干的 Worker。这保证了：正在执行 database.save() 或 httpClient.post() 的线程不受干扰，避免事务中断或连接泄漏。
而 shutdownNow() 会中断所有 Worker，包括正在执行任务的线程。但注意：中断 ≠ 停止。如果任务里是纯 CPU 计算且没检查中断标志，interrupt() 完全无效。
所以别指望 shutdownNow() 能“秒停”一个死循环任务：
// 这种写法会让 shutdownNow() 失效
while (true) {
doWork();
// ❌ 没有检查中断，也没捕获 InterruptedException
}
容易被忽略的生命周期陷阱
线程池状态流转不是一蹴而就的：RUNNING → SHUTDOWN → TIDYING → TERMINATED。其中 TIDYING 阶段会调用 terminated() 钩子方法（可重写），然后才到最终态 TERMINATED。
常见坑点：
- 多次调用
shutdown()没副作用，但重复调用shutdownNow()可能导致重复中断，引发InterruptedException泄漏 -
awaitTermination()返回false并不意味着失败，只是“超时未终了”，此时仍应调用shutdownNow()尝试干预 - 如果任务本身用了
CountDownLatch、CyclicBarrier等同步工具，且未处理中断，线程池可能卡在TIDYING状态永远无法到达TERMINATED
真正优雅的关闭，从来不是靠一个方法，而是状态感知 + 超时控制 + 中断协作的组合。别省那几行代码，也别信“调了就完事”的直觉。
