你有没有遇到过这种情况：写了个 try-finally，结果 finally 块居然没执行？是不是感觉有点懵，甚至开始怀疑人生？害，别慌，这事儿其实挺常见的，咱们今天就来好好唠唠。

先说个前提，Java 的规范里头确实说了finally 块是“应该”执行的。但现实总是比文档复杂，对吧？你懂的，规范是死的，人是活的，有时候它就是不执行，你拿它有啥办法？

那到底啥时候它不执行呢？咱们来盘一盘。

System.exit 一调用，finally 就拜拜了

这个是Zui常见的坑。你写个 System.exit，JVM 直接就地起飞，啥dou不管了。你要是不信，Ke以试试kan，写个 System.out.println 在 finally 里结果你会发现：没执行！

为啥？因为 System.exit 是直接调用 JVM 层的退出函数，相当于“强制关机”，不给任何线程留活路。你要是想在 finally 里Zuo点啥收尾工作，对不起，没门儿。

你可Neng会说：“哎呀，我就是想测试一下kankan finally 会不会执行。”

结果你一调用 System.exit，JVM 直接就崩了啥dou不管了。你再怎么写 finally，它也执行不了。这就像你刚想说“我还有话要说”，结果 守护线程的 finally 也可Neng不执行

这个你可Neng没注意，但也是个大坑。你要是启动的是个守护线程，那它在 JVM 退出的时候，finally 块可Neng还没来得及执行，就被强制终止了。

举个例子，你写了个守护线程，里面有个 try-finally，finally 里打印个 "Daemon finally"，结果 JVM 一退出，它就凉了。你懂的，守护线程是“kan人脸色”的，主线程一挂，它也跟着挂，管你 finally 执行没执行，反正不重要了。

代码大概是这样：

Thread daemon = new Thread -> {
    try {
        Thread.sleep;
    } finally {
        System.out.println; // 可Neng没执行
    }
});
daemon.setDaemon;
daemon.start;

你要是等它执行完，那得kan主线程给不给它机会。主线程一挂，它也跟着挂，finally 就凉了。

无限循环/阻塞操作，finally 也悬了

你要是写了个死循环，比如：

try {
    while {
        // 无限循环
    }
} finally {
    System.out.println;
}

那 finally 块就永远没机会执行。你懂的，死循环就是死循环，JVM 也不会救你。除非你手动中断，不然它就卡在那了。

还有就是你要是调用了 Thread.stop，那 finally 也悬了。虽然这个方法Yi经被废弃了但你要是真用了那 finally 也别指望执行了。为啥？因为 Thread.stop 是强制终止线程，不给它执行 finally 的机会。

你要是不信，Ke以试试kan：

Thread t = new Thread -> {
    try {
        Thread.sleep;
    } finally {
        System.out.println;
    }
});
t.start;
t.stop; // Deprecated but still works

你执行完 t.stop，线程直接被干掉，finally 也跟着凉了。你懂的，这玩意儿不推荐用，但你要是用了那就别指望 finally 了。

finally 里抛异常，也会影响执行

在 Java7 之前，finally 里抛异常会把 try/catch 里的异常给盖过去。现在虽然改了但你要是 finally 里抛异常，还是会影响 try-catch 的执行流程。

比如你写：

try {
    int arr = new int; // OOM
} finally {
    System.out.println;
}

你懂的，OOM 一发生，JVM dou快挂了finally 也别指望执行了。这属于 JVM 层面的“崩溃”，你写啥 finally dou没用。

finally 不执行的“巨坑”

说实话，这事儿其实挺反直觉的。你可Neng会说：“finally 不是一定会执行吗？”

对，大多数情况下是的。但你要是遇到极端情况，比如 JVM 崩了、线程被强制终止、死循环、或者你手动调用了 System.exit，那 finally 就凉了。

你懂的，Java 的异常处理机制虽然设计得挺好的，但现实总是比理论复杂。你得知道这些“边界情况”，不然真出问题了你dou不知道咋回事。

那咋办？

咱就是说你得有备选方案。比如：

用 try-with-resources 代替手动 finally，保证资源释放

用 ShutdownHook ZuoZui后的清理工作

用 addShutdownHook 注册一个 JVM 退出前的清理任务：

Runtime.getRuntime.addShutdownHook -> {
    System.out.println;
}));

注意：这个也拦不住 kill -9 这种强制终止信号。你懂的，系统级的暴力终止，谁dou拦不住。

一下

finally 块不是“万Neng的”，它也有不执行的时候。你得知道这些边界情况，别到时候出了问题还不知道为啥。

比如：

System.exit 一调用，JVM 直接挂，finally 没机会执行

守护线程在 JVM 退出时finally 可Neng没执行

死循环、阻塞操作、线程被 stop，finally 也悬了

finally 里抛异常，可Neng掩盖 try 里的异常

所以你得有备选方案。比如用 try-with-resources，或者用 ShutdownHook ZuoZui后的清理工作。别光靠 finally，不然真出事了你dou不知道咋回事。

Zui后记住一句话：

"The language specification defines what behavior is guaranteed, not what behavior you might observe in all cases."

你得明白，Java 的规范是告诉你“什么一定会发生”，而不是“你kan到的就一定是全部”。你得从 JVM 层面去理解它，别光kan表面。

好了今天就唠到这。你要是真遇到 finally 没执行，别慌，先kankan是不是踩了这些坑。你懂的，代码的世界，永远比你想象的复杂一点点。

---