system.exit()是jvm级强制终止，跳过finally、资源自动关闭及spring销毁逻辑，仅执行shutdownhook；安全退出应优先用框架关闭、自然退出或shutdownhook补救关键清理。
System.exit() 不是“退出程序”，而是直接杀死 JVM 进程。它不走 try-catch-finally，不等非守护线程结束，也不触发 Spring @PreDestroy 或 try-with-resources 的自动关闭。唯一能抓住的“关闭前窗口”，只有 Shutdown Hook —— 且仅当 JVM 是被正常终止（如 System.exit()、Ctrl+C、kill -15）时才执行。
Shutdown Hook 是唯一可靠的清理入口
这是 JVM 提供的、标准且受控的退出前回调机制：
- 必须用
Runtime.getRuntime().addShutdownHook(new Thread(...))注册，钩子本身是一个独立线程 - 多个钩子按注册逆序执行，彼此无依赖、不保证顺序，应设计为完全解耦
- 钩子内不能调用 System.exit()，也不能启动长时间阻塞操作（建议控制在 3–5 秒内）
- 它不会自动帮你 close 文件、Socket 或数据库连接——这些必须显式写在钩子里
资源销毁不能只靠钩子兜底
Shutdown Hook 是补救手段，不是替代方案。真正安全的资源管理要前置：
- 文件、流、Socket 等实现
AutoCloseable的资源，优先用try-with-resources，确保作用域结束即释放 - 数据库连接池、HTTP 客户端等应由框架管理（如 HikariCP 自带 shutdown 方法），并在钩子里显式调用其 close()
- 手动 new 出的 native 资源（如 JNI 句柄）必须在钩子中主动释放，JVM 不负责回收
- 日志缓冲区需在钩子中调用
LoggerContext.stop()或flush()，避免最后几条日志丢失
区分退出场景，避免误杀整个服务
System.exit() 是进程级操作，在复杂系统中极易误用：
- Web 应用、微服务、Spring Boot 项目中，禁用直接调用 System.exit()；改用
ApplicationContext.close()或 Actuator 的/actuator/shutdown - Swing/JavaFX GUI 程序中，用
frame.dispose()+ 让主线程自然退出，而非 System.exit() - 多态分支、RPC 处理器、定时任务中调用 exit，会导致整个 JVM 崩溃，应改为返回错误码或抛出领域异常
- 容器环境（Docker/K8s）中，需配合
STOPSIGNAL SIGTERM，收到信号后等待优雅期再调用 System.exit(0)
退出码要有明确语义，便于外部系统识别
状态码是 JVM 与操作系统、Shell 脚本、K8s 探针通信的唯一接口：
-
System.exit(0)：流程成功完成（如命令行工具导出完毕） -
System.exit(2)：命令行参数解析失败 -
System.exit(3)：配置加载失败 -
System.exit(4)：核心依赖服务不可达 -
System.exit(110)：主动降级退出（K8s 场景常用） - Spring Boot 中推荐用
SpringApplication.exit(ctx, exitCode)，它会先走完 Spring 生命周期再退出
