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，这些都可能真实发生。
哪些场景下资源泄漏最典型
常见问题集中在三类操作上：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 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()。
替代方案更可控也更可靠
多数情况下，return或抛出RuntimeException就能自然结束当前流程，JVM会在所有非守护线程结束后自动退出，并执行所有已注册的shutdown hook。若需主动控制，可：
- 注册Runtime.getRuntime().addShutdownHook()处理关键收尾
- 用Spring的ApplicationRunner或CommandLineRunner做初始化校验，失败时抛异常而非exit
- 命令行工具等顶层入口才考虑System.exit()，且仅限启动失败等不可恢复场景
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
