System.exit 不是安全关闭服务的手段，而是强制终止JVM进程，跳过资源清理、钩子执行和线程优雅停机；应依赖生命周期管理、Spring Boot优雅关闭、手动Shutdown Hook及容器信号协作实现安全退出。
System.exit 本身不是安全关闭服务的手段，而是强制终止 JVM 进程，会跳过资源清理、钩子执行（除非已注册且来得及运行）、线程优雅停机等关键步骤。真正实现服务“安全关闭”，需要绕开或严格限制 System.exit 的使用，转而依赖生命周期管理机制。
避免在业务逻辑中直接调用 System.exit
直接调用 System.exit(0) 或 System.exit(1) 会导致：
- JVM 立即停止，未完成的线程被强制中断（包括正在写文件、提交事务、释放连接的线程）
- 已注册的
Runtime.addShutdownHook可能来不及执行（尤其在高负载或阻塞场景下） - 外部监控/编排系统（如 Kubernetes）无法区分“正常退出”和“崩溃”，影响滚动更新与故障诊断
建议：将退出决策交给容器或框架统一处理，业务代码只抛出异常或返回状态，由顶层捕获并触发标准关闭流程。
使用 Spring Boot 的优雅关闭机制
Spring Boot 2.3+ 默认启用优雅关闭（graceful shutdown），配合 Web 容器（如 Tomcat、Netty）可等待活跃请求完成后再停机：
立即学习“Java免费学习笔记（深入）”；
- 配置
server.shutdown=graceful - 设置最大等待时间：
spring.lifecycle.timeout-per-shutdown-phase=30s - 触发关闭时，调用
ApplicationContext.close()或发送POST /actuator/shutdown（需启用 endpoint） - 此时 Spring 会按序销毁 Bean、执行
@PreDestroy、关闭线程池、释放数据库连接等
手动管理生命周期 + Shutdown Hook（仅作兜底）
若不使用框架，可自行构建关闭信号监听与资源清理链路：
- 监听 OS 信号（如 SIGTERM）：用
Signal.handle(new Signal("TERM"), handler)（注意跨平台兼容性） - 注册 Shutdown Hook 执行关键清理：
Runtime.getRuntime().addShutdownHook(new Thread(this::cleanup)) - 在
cleanup()中关闭线程池（shutdownNow()→awaitTermination()）、断开 DB 连接、刷新缓存、提交日志缓冲区 - 确保钩子内不调用
System.exit，也不阻塞过久（JVM 不保证钩子执行时限）
容器环境下的协作式退出
在 Docker/Kubernetes 中，安全关闭依赖进程对信号的响应：
- Java 进程默认响应
SIGTERM（而非SIGKILL），应避免屏蔽该信号 - Dockerfile 中推荐使用
exec形式启动：ENTRYPOINT ["java","-jar","app.jar"]，确保 Java 进程为 PID 1，能直接接收信号 - K8s 中配置
terminationGracePeriodSeconds（默认 30s），与应用内优雅关闭超时匹配 - 禁止在 shutdown hook 或信号处理器中调用
System.exit—— 它会覆盖原有退出码，干扰容器编排判断
