System.exit()会直接终止JVM，跳过finally、try-with-resources、shutdown hook及Spring关闭流程；典型资源泄漏包括文件未flush、连接未归还、日志未落盘；应优先使用SpringApplication.exit()或抛异常替代。

System.exit会跳过所有资源释放逻辑

System.exit()不是“退出方法”，而是直接终结整个JVM进程。它不等待finally块执行，不触发try-with-resources的自动关闭，也不保证shutdown hook一定运行完毕——只要某个hook卡在阻塞IO或死锁里，整个退出就会挂住。文件流没flush、数据库连接池没close、线程池没shutdown，这些都可能真实发生。

哪些场景下资源泄漏最典型

常见问题集中在三类操作上：

• FileOutputStream写入中途被截断，缓冲区内容丢失
• DataSource或HikariCP连接未归还，导致连接耗尽
• Log4j2或SLF4J的异步日志器未flush，关键错误日志根本没落盘

Web应用和Spring Boot中必须禁用

容器（如Tomcat、Netty）和框架（如Spring Boot）自行管理生命周期。业务代码里调用System.exit()会干扰优雅停机流程，使@PreDestroy方法、SmartLifecycle bean、ApplicationContext关闭钩子全部失效。正确做法是让SpringApplication.exit(context, exitCode)，它先触发完整关闭流程，再安全调用System.exit()。

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

替代方案更可控也更可靠

多数情况下，return或抛出RuntimeException就能自然结束当前流程，JVM会在所有非守护线程结束后自动退出，并执行所有已注册的shutdown hook。若需主动控制，可：

立即学习“Java免费学习笔记（深入）”；

• 注册Runtime.getRuntime().addShutdownHook()处理关键收尾
• 用Spring的ApplicationRunner或CommandLineRunner做初始化校验，失败时抛异常而非exit
• 命令行工具等顶层入口才考虑System.exit()，且仅限启动失败等不可恢复场景