system.exit 退出后仅能执行已注册的 shutdown hook，其他清理逻辑（如 finally、@predestroy、finalize 等）均失效；应避免中途调用 exit，改用自然终止或框架提供的优雅关闭机制。

System.exit 退出后，资源清理代码的执行能力非常有限——它不保证任何业务级清理逻辑能运行，仅保留极窄的“尽力而为”窗口。

shutdown hook 是唯一可执行的 Java 层清理机会

调用 System.exit 后，JVM 会按注册顺序启动所有已注册的 shutdown hook 线程。这是 Java 应用中唯一还能执行的自定义清理逻辑。但要注意：

• hook 必须在 exit 调用前注册，动态注册无效
• 多个 hook 并发执行，无顺序保障；若某一个卡死（如阻塞 IO、死锁），整个退出流程挂起
• hook 中不能调用 System.exit 或 Runtime.halt，否则行为未定义
• hook 运行时 JVM 已进入关闭阶段，不能再加载类、启动新线程或依赖外部服务

常见清理动作在 exit 后大概率失效

以下代码在 System.exit 调用后不会执行，即使它们写在看似“安全”的位置：

Stock Research System

专业股权研究自动化系统，支持6,000-10,000字首发覆盖报告和3,000-5,000字季报更新报告。触发词：股票研究、深度研究、首发覆盖、季报更新、DCF估值。

下载

• try-catch-finally 中的 finally 块（完全跳过）
• try-with-resources 的自动 close() 调用
• 对象的 finalize() 方法（除非显式启用 runFinalizersOnExit，但该方法已废弃且危险）
• @PreDestroy 注解方法、Spring Bean 销毁逻辑、Actuator 关闭端点等框架生命周期回调
• 日志框架的异步刷盘、数据库连接池的优雅归还、Netty Channel 的 graceful shutdown

操作系统层面不等于资源释放完成

虽然 exit 后 JVM 进程终止，操作系统会回收内存、文件描述符等基础资源，但业务语义上的清理仍可能丢失：

• 未 flush 的日志缓冲区内容直接丢弃 → 故障现场无迹可查
• 数据库事务未提交或回滚 → 数据处于中间状态
• 临时文件、锁文件未删除 → 下次启动可能误判为异常中断
• 分布式系统中的服务注册未下线 → 流量继续打到已退出实例，引发 502/超时

替代方案才是解决资源清理的根本路径

与其纠结 exit 后怎么清理，不如避免在任务中途触发 exit：

• 命令行工具：用 return 退出 main，让 JVM 自然终止
• Spring Boot 应用：调用 SpringApplication.exit(context) 触发完整关闭流程
• 多线程任务：用 CountDownLatch 或 CompletableFuture.await() 等待关键子任务结束
• 必须强制退出时（如启动失败），确保此时无活跃资源、无进行中事务、无已打开连接