System.exit() 会强制终止JVM，跳过finally、资源自动关闭及线程等待，易致资源泄漏；安全退出应优先用框架关闭、ShutdownHook和自然退出机制。
Java中调用 System.exit(int status) 可以立即终止当前JVM进程，但它不是“安全退出”的默认方案——是否安全，取决于你是否已妥善处理资源、线程和外部依赖。
System.exit 的本质与风险
System.exit() 会强制终止JVM，跳过普通代码的后续执行流程。它会：
- 立即停止所有非守护线程（包括正在运行的业务线程）
- 不等待
finally块执行（除非在退出前已进入该块） - 绕过
ShutdownHook之外的常规清理逻辑（如 try-with-resources 自动关闭） - 可能造成文件未保存、数据库连接未释放、网络连接中断等资源泄漏
真正安全退出的正确做法
安全退出 ≠ 立即退出，而是“可控、可预测、可恢复”的终止。推荐组合使用以下方式：
-
优先用应用级信号控制生命周期：例如 Spring Boot 应用调用
ApplicationContext.close()或SpringApplication.exit(context, exitCode)，让框架自行完成 Bean 销毁、连接池关闭、事件发布等清理 -
注册 ShutdownHook 处理关键收尾：在 JVM 关闭前执行必要操作，如关闭线程池、刷新日志缓冲区、标记服务下线等
Runtime.getRuntime().addShutdownHook(new Thread(() -> { /* 清理逻辑 */ })); - 避免在多线程/高并发场景中随意调用 System.exit：尤其不能在定时任务、RPC 回调、异步线程中直接调用，否则可能中断其他正常任务
- 仅在主入口或明确受控场景下使用：比如命令行工具解析参数失败、初始化严重异常无法恢复时，作为最后手段
System.exit 的合理使用示例
以下情形可谨慎使用，且建议搭配状态码语义化：
立即学习“Java免费学习笔记（深入）”；
- CLI 工具启动失败：
System.exit(1); // 表示配置错误或依赖缺失 - 健康检查失败且不可恢复：
System.exit(100); // 自定义错误码便于监控识别 - 收到 SIGTERM 后完成优雅等待再退出（需配合信号监听库如
signal4j或 Unixkill -15触发 ShutdownHook）
替代 System.exit 的轻量级退出方式
多数情况下，更推荐“自然退出”而非强制终止：
- 让 main 方法自然结束（适用于单线程简单程序）
- 关闭主线程等待的所有守护线程后，JVM 自动退出
- 使用
Thread.interrupted()或标志位通知工作线程主动退出循环，再 join 等待结束 - Web 应用通过管理端点（如 Actuator 的
/actuator/shutdown）触发框架级关闭流程
