安全关闭的核心是可控、可预测且不破坏资源与状态；应避免随意调用System.exit()，优先通过自然返回、标志位控制或异常捕获统一处理退出，并善用Shutdown Hook做清理。
System.exit() 能立刻终止 JVM，但它不是“安全关闭”的默认方案——真正的安全关闭，核心在于可控、可预测、不破坏资源与状态。直接调用 System.exit() 本身没有安全性，安全性来自你如何包裹它、何时触发、以及是否绕过它。
明确退出意图，区分正常与异常场景
用 status 码传递语义：0 表示流程自然结束（如用户输入 quit、任务完成）；非 0（如 1、127）表示中断、校验失败、初始化异常等。避免在日志未刷盘、文件未 close、数据库连接未释放前就调用 exit。例如：
- 读取配置失败 → System.exit(1)
- 用户主动输入 "exit" → System.exit(0)
- 收到 SIGTERM 信号后优雅清理完毕 → System.exit(0)
注册 Shutdown Hook 做必要收尾
System.exit() 会触发已注册的 shutdown hook（前提是 JVM 尚未 halt）。这是插入清理逻辑的唯一标准时机。比如关闭线程池、刷新缓冲流、写入最后状态标记：
- 用 Runtime.getRuntime().addShutdownHook(new Thread(() -> { /* 清理代码 */ })) 注册
- 确保 hook 中不阻塞、不抛未捕获异常（否则可能卡住整个退出流程）
- 注意：hook 不会在 Runtime.halt() 或安全管理器拒绝 checkExit 时执行
防范意外调用，尤其在多线程/框架环境中
System.exit() 是全局操作，一旦被第三方库（如某些旧版 Dubbo、Log4j 配置错误）或子线程误触发，会导致整个应用静默退出。对策包括：
- 启用 SecurityManager 并配置 policy 文件，禁止非受信代码调用 checkExit
- 在关键模块中检查 System.getSecurityManager() 是否存在并生效
- 在容器化或微服务部署中，优先用 return 结束 main 方法，依赖进程管理器（如 systemd、K8s）控制生命周期
替代方案更利于长期维护
对多数控制台工具而言，System.exit() 并非必须。更安全的做法是让 main 方法自然返回：
- 把主逻辑封装进一个方法，用 return 控制分支退出
- 用 while (running) { ... } 主循环 + 标志位控制退出，比到处 exit 更易测试和调试
- 若需跨多层快速跳出，抛出自定义 RuntimeException（非 SystemExit），并在 main 外层统一捕获并 exit —— 这样能集中处理日志与状态码
真正安全的关闭，不靠 exit 的暴力，而靠结构清晰的退出路径、显式的资源责任归属、以及对 JVM 生命周期的尊重。
