System.exit()是JVM强制终止信号，非安全退出开关；它先并发执行ShutdownHook，再退出，跳过finally、框架销毁回调等常规清理，仅适用于启动失败等极早期场景。

System.exit() 不是生命周期控制的“开关”，而是强制终止信号——它跳过常规退出流程，直接触发 JVM 关闭序列。真正可控的生命周期管理，靠的是分阶段协作：应用层主动关闭、钩子兜底、线程自然结束。

System.exit() 的真实作用：启动关闭序列，不是立即停机

调用 System.exit(status) 后，JVM 并不会瞬间消失。它会按序执行两个阶段：

• 先并发运行所有已注册的 ShutdownHook（关闭钩子），不保证顺序，也不等待某一个完成
• 若启用了 finalization-on-exit（极少启用），再尝试运行未执行的 finalize() 方法
• 之后 JVM 才真正退出，状态码 status 返回给操作系统

注意：它不执行 try-finally 中尚未进入的 finally 块，也不等待守护线程结束，更不会触发 Spring 的 destroy 方法或 Servlet 的 destroy() 回调——这些必须由上层框架在钩子中显式调用。

为什么不能把它当“安全退出”用

直接调用 System.exit() 容易掩盖资源管理问题：

• 数据库连接池未 close → 连接泄漏，下次启动可能连不上
• 异步日志缓冲区未 flush → 最后几条日志丢失
• 正在上传的文件被中断 → 存储不完整或脏数据
• RPC 服务未标记下线 → 注册中心仍认为服务存活，流量继续打进来

这些问题不是 System.exit() 的错，而是说明：退出前该做的事，没在退出前做。

推荐的生命周期控制组合

把退出变成可观察、可干预、可恢复的过程：

• 主流程用信号驱动：Spring Boot 应用优先调用 SpringApplication.exit(context, 0)，它会触发 ApplicationContext.close()，依次销毁 Bean、关闭嵌入式容器、释放连接池
• 关键收尾注册 ShutdownHook：比如关闭自定义线程池、同步刷新指标缓存、向配置中心发送下线通知
• 避免在非主入口调用：定时任务、Netty ChannelHandler、CompletableFuture 回调里禁止出现 System.exit()，否则可能只杀掉部分逻辑，留下“半死”状态
• 命令行工具等单次程序除外：参数校验失败、初始化失败无法恢复时，System.exit(1) 是合理且清晰的选择

退出状态码不是摆设

status 参数是给外部系统看的，不是给 Java 程序自己用的：

• 0 表示成功完成，CI/CD 流水线、shell 脚本依赖它判断是否继续下一步
• 非 0（如 1、128+signal）表示异常，运维可通过 exit code 快速区分是配置错误（code=2）、端口占用（code=3）还是 OOM（code=137）
• 不要用 status 传递业务错误详情——它最多 255，且 shell 只取低 8 位；业务错误应打日志或输出 JSON 到 stdout