System.exit() 不释放资源，而是直接终止 JVM；可靠释放方式包括自然结束 main、显式关闭资源或使用 shutdown hook；Web/Spring Boot 中应避免使用，改用框架提供的退出机制。

System.exit() 本身不释放对象资源，它直接终止 JVM，跳过所有常规清理流程。想确保资源释放，关键不是“在 exit 前加点代码”，而是避开 exit，改用能触发清理的退出路径。

System.exit() 不走清理流程，这是设计，不是缺陷

调用 System.exit(0) 或任何非零值，JVM 会立即中断所有线程，不会执行： • 当前 try 块里的 finally • try-with-resources 的自动 close • 局部变量或对象的 finalize（已弃用且不可靠） • 未完成的异步写入、日志刷盘、数据库提交 它只做两件事：运行已注册的 shutdown hook（如果来得及），然后退出进程。资源是否释放，取决于你有没有把释放动作放在这些可控位置。

真正能释放资源的三种可靠方式

• 自然结束 main 方法：让 main 函数 return，或执行完最后一行。此时所有非守护线程结束，try-with-resources 自动关闭，finally 正常执行，shutdown hook 也会被触发。 • 显式调用资源关闭方法：在 exit 调用前，手动 close() 文件流、DataSource、HttpClient 等——但必须确保这些调用成功且无异常，否则 exit 仍会跳过后续逻辑。 • 用 shutdown hook 承担关键清理：比如注册一个钩子来 flush 日志、标记服务下线、保存内存状态。注意：钩子不能依赖其他正在关闭的组件（如已关闭的线程池），也不保证执行顺序。

Web 和 Spring Boot 场景中别碰 System.exit()

在 Tomcat、Spring Boot 或微服务中，容器负责生命周期管理。调用 System.exit() 会导致： • ApplicationContext 没有 close，Bean 的 destroy 方法不执行 • 数据库连接池未优雅关闭，连接泄漏 • Actuator 端点、健康检查、指标上报突然中断 正确做法是：用 SpringApplication.exit(context) 获取退出码，再由框架自身控制关闭流程；或抛出 RuntimeException 让启动失败，由 SpringApplication 处理善后。

避免资源泄漏的实操建议

• 所有 I/O 资源优先用 try-with-resources，不依赖 finally 或 exit 后的钩子 • 关键状态（如临时文件、锁文件、心跳标记）应在 shutdown hook 中持久化，而不是等 exit 后再写 • 单元测试里禁用 System.exit()，可用 SecurityManager 拦截或 mock Runtime 类验证退出意图 • 若必须退出（如命令行工具解析 --version 后），先完成所有 close/flush/log，再调 exit，且不依赖“之后”的任何逻辑