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 到达