System.exit的优雅退出机制和资源管理实战

System.exit()不是优雅退出机制，而是触发shutdown hook的“硬关机开关”，仅适用于main开头参数解析失败、配置加载崩溃等极早期无业务运行场景；钩子须轻量幂等带超时，Web/Spring Boot中应禁用exit，改用框架生命周期管理或自然退出。

System.exit() 本身不是优雅退出机制，它是一把“硬关机开关”——直接终结 JVM，跳过所有 Java 层清理逻辑。所谓“优雅”，靠的不是 exit 本身，而是用它作为触发器，配合 shutdown hook 做尽力而为的收尾。关键在于：什么时候该按这个开关，以及开关按下后，钩子里能做什么、不能做什么。

System.exit 应该只在极早期失败时触发

它适用的场景非常有限，核心前提是：此时还没有业务线程启动、没有资源正在使用、没有任务在执行。

• main 方法开头参数解析失败（如缺失必要 -c 配置文件）→ System.exit(2)
• 加载核心配置（application.yml）失败且无降级方案 → System.exit(3)
• License 校验不通过或安全策略拒绝启动 → 在初始化最前端调用
• 注意：若框架（如 Spring Boot）已在构造 Bean 阶段运行，此时调用 exit 可能被拦截或引发不可预测行为，应改用 SpringApplication.exit() + 自然退出

Shutdown hook 是唯一能“补救”的机会

exit 被调用后，JVM 会并发启动所有已注册的 shutdown hook。它们是最后的 Java 层执行机会，但不保证一定完成。

• 必须轻量：避免网络请求、数据库写入、长耗时计算；适合刷日志缓冲、关闭连接池、调用 close() 方法
• 必须幂等：可被多次调用而不报错（比如重复调用 channel.close() 是安全的）
• 必须带超时：用 CountDownLatch.await(5, TimeUnit.SECONDS)，防止某个 hook 卡死导致整个进程挂起
• 禁止再调用 System.exit() 或 Runtime.halt()，否则中断当前关闭流程

Web 和 Spring Boot 场景下完全绕开 System.exit

容器和框架自身已封装完整的生命周期管理，主动调用 exit 不仅多余，还会破坏健康检查、服务发现下线、Bean 销毁顺序等关键环节。

• Spring Boot 启动失败？用 SpringApplication.exit(context, 1) 触发标准关闭流程，它会执行 @PreDestroy、DisposableBean、destroy() 等回调
• 需要外部控制退出？暴露 HTTP 管理端点（如 /actuator/shutdown），由运维通过 SIGTERM 或平台指令触发
• 命令行工具或批处理脚本中才考虑 exit，且仅用于明确返回状态码给 shell（如 $? == 0 表示成功）

替代 exit 的自然退出路径更可靠

多数情况下，根本不需要 exit —— 让程序“自然结束”才是最安全的方式。

• 主线程跑完就退出：命令行工具用 return 替代 exit；循环中用 volatile boolean running = true 控制
• 多线程任务等待完成：用 CompletableFuture.allOf() 或 CountDownLatch 等待关键子任务结束，再让 main 线程退出
• 守护线程不阻碍退出：将监控、心跳等非核心线程设为 setDaemon(true)，确保它们不会拖住 JVM
• 资源绑定到 try-with-resources 或 finally 块：确保即使未走 shutdown hook，也能在异常路径下释放