shutdown() 通知线程池不再接受新任务但继续执行已提交和运行中任务；shutdownNow() 尝试中断正在执行的任务、清空队列并返回未执行任务列表，实际终止效果依赖任务是否响应中断。
shutdown() 和 shutdownNow() 的本质区别
调用 shutdown() 是通知线程池：不再接受新任务，但会继续执行已提交的队列中任务和正在运行的任务；shutdownNow() 则是尝试中断所有正在执行的任务，并清空任务队列，返回尚未执行的任务列表。
常见错误是误以为 shutdownNow() 能立即终止所有任务——实际能否真正停止，取决于任务本身是否响应中断（即是否检查 Thread.interrupted() 或捕获 InterruptedException）。
-
shutdown()后需配合awaitTermination(long, TimeUnit)等待自然结束，否则主线程可能提前退出 -
shutdownNow()返回的List是被丢弃的任务，需自行决定是否重试或记录 - 若任务中使用了阻塞 I/O（如
SocketInputStream.read()），中断不会生效，必须配合超时或可关闭的资源（如Socket.close()）
如何确保 awaitTermination 不无限等待
awaitTermination() 是阻塞调用，若超时时间设为过长（如 Long.MAX_VALUE），或任务陷入死循环/无响应状态，会导致关闭流程卡死。
建议始终设置合理超时（如 30 秒），并在超时后根据业务容忍度决策：
立即学习“Java免费学习笔记（深入）”；
- 日志记录未完成任务数：
pool.getCompletedTaskCount()和pool.getTaskCount()可辅助判断积压程度 - 对关键任务，可在
Runnable中嵌入超时逻辑（如用Future.get(timeout, unit)包裹实际工作） - 避免在任务中使用不可中断的 wait/sleep 替代方案（如用
LockSupport.parkNanos()并定期检查中断）
守护线程池与 JVM 退出的关系
默认创建的 ThreadPoolExecutor 使用非守护线程，JVM 不会因主线程结束而退出，直到所有工作线程自然终止。这容易造成“程序看似结束，实则后台线程仍在跑”的假象。
若线程池仅用于短期辅助任务（如日志异步刷盘、监控上报），可考虑自定义 ThreadFactory 将线程设为守护线程：
new ThreadPoolExecutor(1, 1,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<>(),
r -> {
Thread t = new Thread(r);
t.setDaemon(true); // 关键：设为守护线程
return t;
})
注意：守护线程会在 JVM 退出时被强制终止，不保证执行完最后一步（如 flush 缓存、释放锁），因此**不能用于需要强一致性的资源清理场景**。
Spring 环境下 @PreDestroy 的典型陷阱
在 Spring Bean 中用 @PreDestroy 注解调用 shutdown() 很常见，但容易忽略两个关键点：
- 若线程池是通过
@Bean创建且作用域为 singleton，默认由 Spring 管理生命周期；但若手动 new 出来（如在构造器中初始化），@PreDestroy不会触发 - Spring 容器关闭时，多个 Bean 的销毁顺序不确定，若线程池依赖其他 Bean（如数据库连接池），可能在依赖项已关闭后才执行 shutdown，导致任务失败却无日志
- 更稳妥的做法是：在
@PreDestroy中先调用shutdown()，再用awaitTermination()等待，但必须加 try-catch 处理InterruptedException，并恢复中断状态（Thread.currentThread().interrupt()）
真正难处理的，不是关不关得掉，而是关的时候有没有人还在往里 submit 新任务——生产环境常因监听器、回调、定时任务残留导致关闭后仍有任务进入队列。
