Java线程池优雅关闭需组合使用shutdown()、shutdownNow()和awaitTermination()：shutdown()拒绝新任务但执行完已提交任务；shutdownNow()尝试中断运行任务并清空队列；awaitTermination()配合前者实现阻塞等待，超时后可兜底调用shutdownNow()。
Java中关闭线程池不能只调用shutdown()或shutdownNow()就完事——关键在于理解它们的行为差异，并组合使用才能真正“优雅”。
shutdown()：拒绝新任务，但放行所有已提交任务
调用后线程池进入SHUTDOWN状态，表现为：
- 不再接受
submit()或execute()的新任务，后续提交会抛RejectedExecutionException - 正在运行的任务继续执行
- 等待队列中的任务仍会被线程逐个取出并执行
- 线程池本身不阻塞，也不会中断任何线程
它只是“关门”，不赶人——适合常规下线、服务重启等需要保障任务完整性的场景。
shutdownNow()：尝试中断运行中任务，清空队列
调用后线程池立即进入STOP状态，行为更激进：
立即学习“Java免费学习笔记（深入）”；
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 同样拒绝新任务
- 对所有工作线程调用
Thread.interrupt()（仅对响应中断的任务有效） - 直接清空任务队列，返回未执行的
Runnable列表（注意：可能被封装，不等于原始提交对象） - 不保证正在跑的任务一定立刻停止——若任务未检查中断状态或未调用
sleep/wait/join/lockInterruptibly等可中断方法，interrupt()无效
它像拉电闸，适合故障熔断、紧急终止等高优先级停机需求，但需确保业务逻辑支持中断语义。
awaitTermination()：让shutdown真正“落地”的关键搭档
shutdown()本身不等待，所以必须配合awaitTermination()才构成完整优雅流程：
- 该方法会阻塞当前线程，直到：所有已提交任务完成，或超时，或当前线程被中断
- 返回
true表示任务全部结束；false表示超时仍有任务在跑 - 典型模式是：先
shutdown()，再awaitTermination()，超时后补shutdownNow()兜底
单独用awaitTermination()没意义——它必须在shutdown()或shutdownNow()之后调用才生效。
推荐关闭模板：兼顾安全与可控
生产环境建议采用分阶段策略：
- 调用
executor.shutdown()，停止接收新任务 - 调用
awaitTermination(30, SECONDS)，给任务合理完成时间 - 若返回
false（超时未结束），再调用shutdownNow()强制干预 - 再次
awaitTermination(5, SECONDS)等待强制中断结果 - 捕获
InterruptedException并恢复中断状态：Thread.currentThread().interrupt()
这种“先礼后兵”方式既尊重任务完整性，又避免无限等待，是大多数服务优雅下线的标准实践。
