优雅退出应通过Shutdown Hook触发线程池两阶段关闭，而非直接System.exit()；先shutdown()放行未开始任务，再awaitTermination()等待完成，超时后shutdownNow()中断并二次等待，Spring中优先用@PreDestroy或DisposableBean。
直接调用 System.exit() 会跳过所有清理逻辑，线程池来不及关闭就进程终结，任务丢失、资源泄漏、状态不一致风险极高。真正“优雅”的退出，核心不是强行终止 JVM，而是让线程池自己按序收尾——靠 shutdown() + awaitTermination() 配合 JVM 关闭钩子（Shutdown Hook）来实现。
为什么不能直接 System.exit()？
它属于 JVM 级硬杀：绕过 finally、try-with-resources、已注册但未执行完的 Shutdown Hook，甚至可能卡死在某个钩子里。线程池里的正在运行任务、排队中任务、连接、文件句柄等，全部被粗暴截断。这不是退出，是崩溃。
正确姿势：用 Shutdown Hook 触发线程池两阶段关闭
把线程池关闭逻辑封装进一个轻量、幂等、带超时的钩子函数里，由 JVM 在收到退出信号（如 System.exit() 或外部 SIGTERM）时自动触发：
- 先调用
executor.shutdown()：拒绝新任务，放行已提交但未开始的任务，让正在跑的任务自然完成 - 调用
awaitTermination(60, TimeUnit.SECONDS)：最多等 60 秒，给线程池自我清理的时间 - 若超时未结束，再调用
executor.shutdownNow()：尝试中断所有仍在运行的线程，并取消队列中待执行任务 - 再次
awaitTermination(10, TimeUnit.SECONDS)：给中断响应留出缓冲时间，避免无限阻塞钩子 - 捕获
InterruptedException并恢复中断状态，防止吞掉关键信号
Spring 环境下更推荐生命周期管理
在 Spring Boot 中，应优先使用框架自身的生命周期机制，而非手动注册 Shutdown Hook：
- 实现
DisposableBean接口，重写destroy()方法，在其中执行线程池关闭逻辑 - 或使用
@PreDestroy注解标注清理方法，由 Spring 容器在上下文关闭时调用 - 确保线程池 Bean 是单例且由 Spring 管理，这样 shutdown 才能随应用关闭自动触发
- 避免在
@PreDestroy中调用System.exit()，否则会干扰容器正常停机流程
什么时候才该用 System.exit()？
它只适合极少数主动控制退出时机的场景，且必须配合钩子：
- 命令行工具任务完成，需明确返回码给 shell（如
System.exit(0)） - 健康检查失败，确认无法恢复，需自终止并通知上层（如 K8s liveness probe）
- 启动阶段发现致命错误（如 license 校验失败、核心配置缺失），根本无法进入主流程
- 绝对不要在 Web 应用业务逻辑、Filter、Controller 中调用；也不要在线程池钩子内部再调用 exit
不复杂但容易忽略：优雅退出的关键不在“怎么停”，而在“谁来触发”和“停得是否干净”。用对钩子，配好两阶段关闭，线程池才能真正交出最后一份结果再离场。
