System.exit()不是退出方法而是JVM强制终止指令，会中断所有非守护线程、跳过finally和资源关闭，仅执行ShutdownHook；安全退出需配合框架关闭、自然返回、标志位控制及规范退出码。
System.exit() 不是“退出方法”，而是向 JVM 发送终止信号的指令。它不会等待当前逻辑执行完毕，也不保证资源释放或状态一致——是否安全，取决于你是否提前安排好退出路径和清理责任。
System.exit 的真实行为
调用 System.exit(status) 后，JVM 立即进入关闭流程，但只做三件事：
- 中断所有非守护线程（包括正在写数据库、刷日志、上传文件的线程）
- 跳过尚未执行到的 finally 块、try-with-resources 的 close()、@PreDestroy 方法
- 仅执行已注册的 ShutdownHook，且不保证执行顺序或完成时间
它不是“优雅退出”，而是“强制收摊”。若 hook 中有阻塞操作（如等待网络响应、锁未释放），进程会卡住，直到超时或被 kill -9 终止。
哪些情况可能让 System.exit 失效或异常
看似简单的一行代码，在实际运行中常因环境干扰而失效：
- 在 Spring Boot ApplicationRunner 中调用：部分框架会捕获并压制该调用，导致无反应
- 被 SecurityManager 拦截：未授权 exitVM 权限时抛出 SecurityException，而非退出
- 容器或服务管理器拦截：K8s、systemd、Dubbo 等可能重定向或忽略 exit 调用
- 异步线程中误调用：主线程仍在阻塞（如等注册中心），此时 exit 可能延迟生效甚至被丢弃
退出码不是随意填的数字
退出状态码是程序与操作系统、CI/CD、监控系统通信的唯一语义接口：
- 必须用 0 表示完全成功；非 0 表示失败，推荐使用 1–127 区间
- 避免负数（如 -1 → 实际为 255）、避免 143（与 SIGTERM 冲突）、避免大于 255 的值
- 建议按语义分码：2=参数错误，3=配置缺失，100=核心依赖不可用，105=健康检查超时
Shell 脚本、K8s liveness probe、运维巡检都依赖这个数字做判断，传错会导致故障被掩盖。
真正安全的退出组合策略
靠一行 System.exit 无法实现安全退出，必须配合生命周期管理机制：
- Web 应用优先走框架级关闭：Spring Boot 调用 SpringApplication.exit(ctx, code)，触发 Bean 销毁、连接池关闭、事件广播
- 命令行工具中，用 return 替代 System.exit(0)；main 方法自然结束更可控、可测试
- 必须清理的资源，注册 ShutdownHook：如 threadPool.shutdownNow()、logger.flush()、临时文件删除
- 多线程场景下禁用直接 exit：改用 volatile 标志位 + join 主动通知各线程退出，再统一收尾
ShutdownHook 是唯一被 JVM 保障执行的清理入口，但它只是“尽力而为”——kill -9 或 JVM 崩溃时仍会跳过。
