system.exit() 会立即终止jvm，跳过finally执行；它不是方法返回而是进程终结，不触发栈展开、shutdown hooks（除非显式注册）或资源自动清理，应改用return、try-with-resources或shutdown hook等可预测机制。
因为 System.exit() 不是“退出方法”，而是“杀死 JVM”——它让整个虚拟机瞬间停摆，连 finally 的字节码指令都来不及加载执行。
System.exit() 的本质是进程终结，不是控制流跳转
Java 规范明确将 System.exit() 列为 finally 的标准例外。它不走任何 Java 层的异常处理或方法返回流程，而是直接向操作系统发送终止信号。JVM 收到后立即释放所有线程、丢弃栈帧、中止字节码解释器——此时 try-catch-finally 结构已失去存在基础。
- 不同于 return：return 会暂存返回值，再跳进 finally 执行完才真正返回
- 不同于未捕获异常：异常仍会触发栈展开，finally 在向上抛出前执行
- System.exit() 没有“之后”：没有栈展开、没有 finally 调度、甚至不运行 shutdown hooks（除非显式注册）
常见误用场景与风险
很多开发者以为把 cleanup() 放在 System.exit() 前面就“安全了”，但实际仍有隐患：
- 若 cleanup() 内部调用 System.exit() 或发生未捕获异常，后续逻辑仍中断
- 多线程环境下，main 线程调用 exit() 时，其他线程可能正执行关键资源操作，无机会清理
- 测试中频繁使用 exit() 容易掩盖资源泄漏，尤其在连接池、文件句柄等场景下
更可靠的替代方案
真正需要退出时，应避免依赖 finally 的时机，改用可预测、可干预的机制：
- 用 return 从 main 方法自然退出，确保 finally 正常触发
- 对可关闭资源（如 FileInputStream、Connection），优先用 try-with-resources —— 编译器生成的 close() 调用独立于 finally 执行路径
- 注册 shutdown hook：Runtime.getRuntime().addShutdownHook(new Thread(() -> { /* 关键清理 */ }))，它能在 exit() 和大多数正常关闭中运行（但对 halt() 和 kill -9 无效）
- 业务层统一退出逻辑：抛出自定义 ExitException，由顶层 handler 捕获并执行清理 + return，而非直接 exit()
如何验证 finally 是否被跳过
写个简单测试就能确认：
- 在 try 块末尾打印 “in try”，catch 中打印 “in catch”，finally 中打印 “in finally”
- 在 try 或 catch 内调用 System.exit(0)，运行后只会看到前两条输出
- 换成 return 或 throw new RuntimeException()，则三条都会输出
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
