shutdown() 是默认且唯一推荐的关闭方法，它仅停止接收新任务并等待已有任务自然完成；shutdownNow() 仅尝试中断运行线程、清空队列并返回未执行任务，不保证任务终止；awaitTermination() 是 shutdown() 的必要配合，用于等待真正关闭；测试中须隔离线程池避免状态污染。
shutdown() 是默认选择，不是备选方案
绝大多数业务场景下，shutdown() 就是你该调用的唯一方法。它不暴力、不跳过、不丢任务——只是关掉“进水阀”，让“池子里的水”自然流完。
常见错误是：一看到服务要下线，立刻 shutdownNow()，结果日志里一堆 InterruptedException，数据库写了一半的记录没提交，MQ 消息重复投递……这些都不是线程池的问题，是你提前拔了电源。
shutdownNow() 的真实作用不是“立刻停”，而是“尽力撤”
shutdownNow() 不保证任务停止，只做三件事：尝试中断正在运行的线程（靠 Thread.interrupt()）、清空队列、返回未执行的 Runnable 列表。它对以下任务无效：
• 未响应中断的循环（比如 while (true) { ... } 且没检查 Thread.interrupted()）
• 正在执行 IO 或 native 调用且不可中断的操作
• 已进入 finally 块但还没完成清理逻辑的任务
所以别把它当“强制退出键”，它更像一个带警告的撤退信号。
awaitTermination() 不是可选配件，而是 shutdown() 的必要搭档
只调 shutdown() 不等于线程池已关闭——它只是发出了“请慢慢收工”的指令。你必须配合 awaitTermination(long timeout, TimeUnit unit) 等待真正结束，否则主线程可能提前退出，导致 JVM 在任务还在跑时就终止。
实操建议：
• 设定合理超时（如 30 秒），太短容易误判，太长影响下线节奏
• 超时后若仍没结束，再考虑是否补 shutdownNow()（仅限紧急兜底）
• 别忘了检查返回值：if (!executor.awaitTermination(30, TimeUnit.SECONDS)) { ... }
测试里乱用全局线程池，等于埋定时炸弹
单元测试中复用静态或 Spring 管理的线程池，会导致测试间状态污染：前一个 test 调了 shutdown()，后一个 test 提交任务直接抛 RejectedExecutionException；或者 shutdownNow() 中断了别的 test 正在跑的 mock 定时任务。
正确做法：
• 每个 test 创建自己的 newFixedThreadPool(1) 或 newSingleThreadExecutor()
• 显式调用 shutdown() + awaitTermination()，并放在 finally 块里
• 避免使用 Executors.newCachedThreadPool()，它的无界队列和无限扩容在测试中极易失控
最常被忽略的一点：线程池关闭不是单次函数调用就能闭环的事。它是一组协作行为——提交方要感知生命周期，任务本身要响应中断，调用方要等待确认，测试环境要隔离干净。少其中一环，就不是“优雅”，而是“侥幸”。
