system.exit()仅触发jvm关闭流程，不自动释放外部资源；资源注销依赖显式注册的shutdownhook及应用自身关闭逻辑，且应优先使用框架级关闭机制如springapplication.exit()。
System.exit 本身不注销外部资源，它只是触发 JVM 关闭流程的“开关”。真正负责注销外部资源（如数据库连接、线程池、文件句柄、HTTP 客户端、缓存连接等）的，是你主动注册的 ShutdownHook，以及应用自身的关闭逻辑。直接调用 System.exit() 反而会跳过大部分清理动作——除非你提前把注销逻辑放在正确位置。
ShutdownHook 是唯一可控的资源注销入口
当 System.exit() 被调用（或收到 SIGTERM、Ctrl+C），JVM 会并发执行所有已注册的 ShutdownHook 线程。这是你唯一能确保执行的“关机前窗口”：
- 用 Runtime.getRuntime().addShutdownHook(new Thread(() -> { ... })) 注册，钩子内写明文注销逻辑，例如：dataSource.close()、executor.shutdownNow()、httpClient.close()
- 钩子必须轻量、无阻塞：避免网络请求、大文件写入；建议加超时控制（如 awaitTermination(3, SECONDS)）
- 多个钩子无执行顺序保证，彼此应解耦；若需串行（如先停服务再关连接），需手动加锁或合并为单个钩子
- 钩子中禁止再调用 System.exit() 或 Runtime.halt()，否则行为未定义
优先走框架级关闭路径，而非 System.exit()
在 Web 或 Spring Boot 等环境中，直接调用 System.exit() 会绕过整个应用生命周期管理，导致资源无法注销：
- Spring Boot 应使用 SpringApplication.exit(context, exitCode)，它会触发 @PreDestroy、/actuator/shutdown 端点（需配置 management.endpoint.shutdown.enabled=true），通过 HTTP 请求触发优雅关闭
- 嵌入式场景可显式调用 applicationContext.close()，等效于容器标准关闭流程
资源注销不能只靠钩子，要前置到正常流程中
ShutdownHook 是兜底手段，不是主逻辑。可靠注销依赖日常编码习惯：
- I/O 资源（文件、Socket、流）优先用 try-with-resources，作用域结束自动 close，不受 System.exit() 影响
- 数据库连接池（如 HikariCP）、HTTP 客户端（如 OkHttp、Apache HttpClient）提供 close() 或 shutdown() 方法，应在业务结束或配置销毁时显式调用
- 自定义资源（如 JNI 句柄、临时锁文件、心跳标记）应在钩子中持久化状态并释放，但前提是它们已被设计为可安全注销
容器与信号环境下的实际注销配合
在 Docker/K8s 中，System.exit() 不是退出信号的响应者，而是结果。真正关键的是接收 SIGTERM 并完成注销：
- Java 进程默认响应 SIGTERM，会触发 ShutdownHook；确保镜像中未覆盖 STOPSIGNAL 或禁用信号传递
- 若需更精细控制（如等待请求处理完），可用 Signal.handle(new Signal("TERM"), sig -> { shutdownGracefully(); }) 拦截信号，再调用注销逻辑
- K8s 的 terminationGracePeriodSeconds 应大于钩子最大耗时（建议 ≥10 秒），避免被 SIGKILL 强制终止
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
