system.exit() 仅触发 jvm 关闭流程，不自动释放资源；需主动注册轻量幂等的 shutdown hook 并显式关闭线程池、连接池等核心资源，避免阻塞与异常中断，且仅在可控业务终点或不可恢复错误时调用。
System.exit() 本身不关闭资源，它只是触发 JVM 关闭流程的“开关”。真正负责资源释放的是 shutdown hook —— 你得主动注册、精心编写，才能实现优雅关闭。
明确退出触发时机
System.exit() 应只在可控、明确的业务终点调用，比如：
- 命令行工具完成全部任务后
- 健康检查连续失败且判定不可恢复时
- 收到自定义关闭端点（如 /actuator/shutdown）请求后
- Spring Boot 启动失败需中止（配合 SpringApplication.exit() 获取退出码）
避免在 Web 容器、Android Activity 或被 systemd/K8s 管理的进程中主动调用；这些场景应依赖 SIGTERM 信号，由外部管理器发起关闭。
注册轻量幂等的 Shutdown Hook
钩子必须是独立线程，JVM 在 exit 后并发启动所有已注册钩子。关键约束：
- 不做阻塞操作：不用 join()、wait()，改用带超时的 CountDownLatch.await(10, SECONDS)
- 显式释放核心资源：调用线程池 shutdownNow()、Netty EventLoopGroup.shutdownGracefully()、DataSource.close()
- 捕获并吞掉异常：防止单个钩子抛异常中断整个清理链
- 禁止再调用 System.exit() 或 Runtime.halt()：否则导致二次终止或清理中断
区分“优雅退出”与“强制终止”
System.exit() 是 JVM 级终结，它会跳过 try-with-resources、finally 块、甚至未执行完的钩子 —— 这不是 bug，是设计行为。因此：
- 启动失败、安全熔断、配置严重错误等无法继续场景，才用 System.exit(1)
- 常规业务结束（如用户点击“退出”）不该用它；Android 应 finish 所有 Activity 后交由系统回收，Web 应走框架生命周期
- 永远不要在多线程环境或库代码里调用，极易引发状态不一致
验证与兜底机制
仅靠钩子不够可靠，需叠加防护：
- 为关键钩子设置超时（如 15 秒），超时后记录 warn 日志并强制返回
- 使用 try-finally 包裹关键资源操作（如文件写入），确保即使钩子未触发也能保底释放
- 在容器化部署中，配合 liveness/readiness 探针 + preStop hook，确保 SIGTERM 先于 kill -9 到达
