system.exit()仅触发jvm关闭流程，不负责资源释放；安全释放依赖shutdownhook——需注册轻量、无阻塞的清理逻辑，配合框架关闭流程（如spring boot的exit()或/actuator/shutdown），并避免在异步线程、库代码及容器中滥用。
System.exit() 本身不负责释放资源，它只是触发 JVM 关闭流程的“开关”。真正实现安全释放资源，靠的是在 JVM 关闭前执行的清理动作——核心是 ShutdownHook，而不是 System.exit() 这个调用本身。
ShutdownHook 是资源清理的关键载体
System.exit() 会触发所有已注册的 ShutdownHook 执行，这是你唯一可控、被保证执行的清理时机（前提是没被 kill -9 中断）。所有需要释放的资源——数据库连接、线程池、文件句柄、缓存写回、日志刷盘——都应放在 Hook 里做：
- 用 Runtime.getRuntime().addShutdownHook() 注册一个新线程，里面写清理逻辑
- 确保钩子内操作轻量、无阻塞：避免网络请求、长耗时 I/O；超时控制在 3–5 秒内
- 多个钩子并发执行，若存在依赖关系，需自行加锁或串行化
- 钩子里不能再调用 System.exit()，否则行为未定义
不能只靠 System.exit()，必须配合应用级关闭流程
对 Web 或框架型服务（如 Spring Boot），直接调 System.exit() 是下策。应优先走框架自身的关闭路径，它们内部已集成 ShutdownHook 和 Bean 销毁逻辑：
- Spring Boot 应用推荐调用 SpringApplication.exit(context, exitCode)，它会触发上下文关闭、Bean 销毁、连接池归还等全套流程
- 启用 Actuator 的 /actuator/shutdown 端点（需配置开启），通过 HTTP 请求触发优雅关闭
- 手动调用 ApplicationContext.close()，适用于嵌入式或测试场景
状态码要语义化，但别指望靠它释放资源
System.exit(n) 的参数 n 只是返回给操作系统的退出码，0 表示成功，非 0 表示异常，超出 255 会取模。它本身不参与资源管理：
- 用 System.exit(0) 表示正常结束（如 CLI 工具完成任务）
- 用 System.exit(1) 或自定义码（如 100、110）表示特定错误或主动降级，便于监控识别
- 不要为“释放资源”而选某个特殊码——资源是否释放，取决于钩子有没有注册、有没有跑完，和码值无关
哪些情况不该用 System.exit()
它不是通用退出指令，而是最后手段。以下场景应避免直接调用：
- 在异步线程、定时任务、RPC 回调中——可能中断其他正在运行的任务
- 在库代码或 SDK 中——会破坏调用方的生命周期控制
- 在容器（Docker/K8s）中未配合 SIGTERM 处理——导致强制终止、连接未断开、Pod 无法及时下线
- Web 容器环境（如 Tomcat）中——可能被 SecurityManager 拦截，抛出 SecurityException
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
