system.exit()仅是触发jvm关闭的硬开关，优雅关机依赖提前注册的轻量、幂等、带超时的shutdown hook；适用于main早期失败、配置崩溃、license校验失败等进程级终止场景，禁用于web容器和运行中服务。
System.exit() 本身不实现优雅关机，它只是触发 JVM 关闭流程的“硬开关”。真正实现优雅关机，靠的是在调用它之前注册好轻量、幂等、带超时的 shutdown hook，并严格限定调用时机——尤其在复杂应用中，错用会直接杀死整个服务。
只在极早期或明确进程终点调用
System.exit() 的语义是“这个 Java 进程该结束了”，不是“这次请求/这个线程该停了”。在 Spring Boot、Web 容器、微服务等复杂系统中，它仅适用于以下有限场景：
- main 方法开头参数解析失败（如缺失必需配置文件），尚未进入框架初始化阶段
- 核心配置加载崩溃且无降级路径（如 application.yml 格式错误、加密密钥无效）
- License 校验失败或安全策略拒绝启动，在 ApplicationContext 构造前就终止
- 命令行工具完成全部任务后，需向 Shell 返回明确状态码（如 $? == 0）
用 shutdown hook 做唯一可控的清理入口
JVM 在 System.exit() 后会并发执行所有已注册的 shutdown hook，这是你最后一次执行 Java 层清理的机会。但它不是万能兜底，必须精心设计：
- 钩子内只做轻量操作：刷日志缓冲、调用 connectionPool.close()、threadPool.shutdownNow()，避免网络请求或数据库写入
- 必须幂等：重复调用 channel.close() 或 dataSource.close() 不应报错
- 必须带超时：用 CountDownLatch.await(5, TimeUnit.SECONDS)，防止某个钩子卡死拖住整个退出
- 捕获并吞掉所有异常：单个钩子抛异常不会中断其他钩子，但未捕获异常可能被静默丢弃
- 禁止在钩子里再调用 System.exit() 或 Runtime.halt()，否则清理流程会被强行中断
复杂系统中优先绕开 System.exit()
Spring Boot、Tomcat、Kubernetes 等环境已有成熟生命周期管理机制，主动调用 System.exit() 反而会破坏它们：
- 启动失败时，用 SpringApplication.exit(context, exitCode) 替代 —— 它先执行 @PreDestroy、DisposableBean 和 destroy() 回调，再调用 System.exit()
- 运行中需要关闭，暴露 /actuator/shutdown 端点，由运维发 SIGTERM，让框架按顺序下线 Bean、注销服务发现、等待活跃请求结束
- 容器化部署时，配合 Kubernetes 的 preStop hook + terminationGracePeriodSeconds，确保 SIGTERM 先于 kill -9 到达
- 库代码或被依赖模块中绝对禁用 System.exit() —— 它剥夺调用方对进程生命周期的控制权
退出码要有业务含义，别全用 0 或 1
退出码是系统间通信的语言，Shell 脚本、CI 流水线、K8s 探针都依赖它判断成败：
- 0：成功完成预期目标（如导出文件完成、健康检查通过）
- 2：命令行参数错误（main 中 args 解析失败）
- 3：配置加载失败（application.properties/yml 读取或解析异常）
- 4：外部依赖不可用（数据库连接超时、Redis 拒绝连接）
- 127：系统级命令缺失（如调用 git 但环境未安装）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
