finally块在System.exit(0)时不会执行，因JVM立即终止，跳过所有待执行字节码；该行为是规范定义而非bug，且在JDK 8–21中一致。
finally 块在 System.exit(0) 时不会执行
Java 的 finally 块设计初衷是“几乎总能运行”，但 System.exit(0) 是个明确的例外：它会立即终止 JVM，跳过所有待执行的字节码，包括 finally 中的逻辑。这不是 bug，而是 JVM 规范定义的行为。
常见错误现象：
你写了资源关闭、日志记录或状态重置逻辑在 finally 里，本地测试都正常，但一调用 System.exit(0)（比如某些脚本启动器、测试框架的强制退出），这些逻辑就彻底消失——没报错，也没日志，就是“凭空不执行”。
-
System.exit(int)会触发 JVM 的 shutdown hook，但不会回退到当前 try-catch-finally 的控制流中 - 即使
finally里有return或抛异常，也完全没机会进入 - 该行为在所有 JDK 版本（8–21）中一致，与是否启用 JIT、是否在主线程调用无关
哪些情况会让 finally 跳过执行
除了 System.exit()，还有几个真实场景会导致 finally 失效，它们共同点是“JVM 级别中断”，而非 Java 层面的控制流转移。
-
Runtime.getRuntime().halt(int)：比exit()更暴力，连 shutdown hook 都不走 - JVM 被操作系统信号强杀（如
kill -9） - 线程被
Thread.stop()（已废弃但仍有遗留代码调用） - 发生
OutOfMemoryError并导致 JVM 崩溃（非所有 OOM 都如此，但堆外内存耗尽时常见）
注意：return、break、continue、普通异常甚至 throw 新异常，都不会阻止 finally 执行——只有上面这些“进程级终结”才会。
立即学习“Java免费学习笔记（深入）”；
想确保清理逻辑运行？别依赖 finally
如果业务逻辑要求“必须执行某段代码”（比如释放本地句柄、写入审计日志、通知外部服务），把关键操作放在 finally 里是靠不住的，尤其当系统存在主动退出路径时。
- 优先用
try-with-resources处理可关闭资源，它的close()调用在字节码层面更可控 - 将关键清理逻辑注册为 shutdown hook：
Runtime.getRuntime().addShutdownHook(new Thread(() -> { /* 清理 */ })) - 避免在业务代码中直接调用
System.exit()；改用抛异常 + 外层统一捕获退出，给finally留出执行机会 - 如果必须用
System.exit()，提前手动调用清理函数，而不是指望它自动触发
如何验证 finally 是否真的被跳过
不要只靠肉眼检查逻辑，用最直白的方式确认行为：在 finally 里加带副作用的操作，观察是否发生。
public class FinallyTest {
public static void main(String[] args) {
try {
System.out.println("try");
System.exit(0);
} finally {
System.out.println("finally"); // 这行永远不会输出
Files.write(Paths.get("flag.txt"), "ran".getBytes()); // 文件也不会生成
}
}
}运行后你会发现：try 输出了，但 finally 里的 System.out.println 和文件写入全都没发生。这个现象在 IDE 控制台和 Linux 终端下表现一致，是可稳定复现的 JVM 行为。
真正容易被忽略的是：这种跳过不抛任何异常、不打印警告、也不进 debugger 断点——它安静得像没写那几行代码一样。所以只要代码路径里存在 System.exit()，就得人工检查所有依赖 finally 的保障逻辑是否还成立。
