多数业务应优先用 shutdown()，它拒绝新任务但等待已有任务完成；shutdownNow() 强制中断运行中线程并返回未执行任务，仅适用于超时不可接受的场景。
shutdown() 和 shutdownNow() 到底该用哪个
多数人一上来就调 shutdownNow()，以为“立刻停”更干净，结果任务被强行中断、状态丢失、日志打乱。其实两者语义完全不同：shutdown() 是温柔告别——不再接受新任务，但会等已提交的线程执行完；shutdownNow() 是强制断电——尝试中断所有正在运行的线程，并返回尚未执行的 Runnable 队列。
真实场景中，90% 的业务应优先选 shutdown()，尤其涉及数据库写入、文件落盘、HTTP 回调等需保证完成的操作。只有在超时等待不可接受（比如服务优雅下线倒计时只剩 2 秒），才考虑 shutdownNow()，且必须配合后续的中断响应逻辑。
为什么 awaitTermination() 总是超时返回 false
常见错误是调了 shutdown() 就直接 awaitTermination(5, TimeUnit.SECONDS)，没意识到：这个方法只阻塞等待「线程池真正终止」，而终止的前提是所有任务执行完毕 + 所有工作线程退出。如果某个任务死循环、IO 卡住、或忘了处理 InterruptedException，它就会永远等不到 true。
正确做法是：
立即学习“Java免费学习笔记（深入）”；
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 给关键任务设置超时（如
Future.get(30, TimeUnit.SECONDS)） - 在线程内检查
Thread.currentThread().isInterrupted()并主动退出 -
awaitTermination()后一定要判断返回值，false 时按需记录未完成任务或触发告警 - 别指望单次调用就能覆盖所有情况，可循环重试 + 递增等待时间（如 1s → 3s → 5s）
线程池关闭后 submit() 抛 RejectedExecutionException 怎么办
这是最典型的资源泄漏信号：线程池已关闭，但还有代码试图往里塞任务。不是线程池关错了，而是调用方没同步感知生命周期。
根本解法不在池本身，而在控制流设计：
- 把
ExecutorService封装进一个管理类，暴露submitIfRunning(Runnable)方法，内部先检查isShutdown() - 使用 Spring 等容器时，通过
@PreDestroy统一关闭，避免多个 Bean 各自操作同一池 - 单元测试里别复用全局池，每个 test 用
newFixedThreadPool(1)+ 显式shutdown()，防止干扰 - 日志里加标识，比如打印
"[Pool-closed] Ignored task: " + task.getClass().getSimpleName()，快速定位漏关点
关闭前要不要清空队列或取消 pending 任务
不需要手动清空。线程池关闭时，shutdown() 会自然让队列中的任务逐个被执行；shutdownNow() 返回的 List<runnable></runnable> 就是那些没来得及出队的任务——你可以遍历它们做补偿（如写入延迟队列重试），但别试图「清空」，因为队列本身不提供安全清除接口，强行 getQueue().clear() 可能破坏内部状态。
真正要注意的是：如果用了带界队列（如 ArrayBlockingQueue），且设置了拒绝策略为 DiscardPolicy 或 CallerRunsPolicy，关闭前务必确认没有任务正被拒绝却未被感知。建议统一用 AbortPolicy，让异常暴露问题，而不是静默吞掉。
复杂点往往藏在异步回调链里：A 提交任务到池，B 在任务里又提交 C 到同一个池——这种嵌套调用下，关池时机稍有偏差，C 就可能被拒。这时候光关池不够，得配合状态标记 + 提交前校验。
