finally并非绝对执行，它仅在jvm可控且控制流能抵达的前提下运行；编译器将finally代码复制到所有出口路径，覆盖正常结束、异常抛出、catch处理及return等场景，但system.exit()、jvm崩溃、守护线程终止、死锁或不可中断阻塞会导致其失效。
Java 中 finally 代码块并不是“绝对保证”一定会执行，但它的设计目标和编译机制让它在绝大多数正常流程中都能可靠运行——这种“几乎总是执行”的特性，源于 JVM 的字节码层面保障，而非语言层面的无条件承诺。
编译器自动复制逻辑，覆盖所有出口路径
Java 编译器（javac）在生成字节码时，并不会简单地把 finally 块当作一个独立语句顺序执行。而是将 finally 中的代码复制到 try 块的所有可能退出点之后：包括正常执行完、抛出异常、catch 处理完、甚至 try/catch 内部的 return 语句之前。这意味着只要控制流能“走出”try 或 catch 块（且未被外部强行中断），JVM 就已把清理逻辑嵌入了每条路径。
它应对的是程序逻辑层面的不确定性，不是系统级崩溃
finally 的可靠性针对的是 Java 程序自身的运行分支： - try 中没异常 → 执行完后跳转到 finally - try 抛异常且被 catch 捕获 → catch 执行完后进入 finally - try 抛异常且未被捕获 → 在异常向上传递前，先执行 finally - try 或 catch 中有 return → 先暂存返回值，执行 finally 后再真正返回
这些都属于 JVM 可调度、可控制的执行流，编译器和运行时能精确介入。
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
真正会跳过 finally 的，是 JVM 本身不再参与调度的情况
一旦程序脱离了 Java 运行时的管理能力，finally 就失去作用机会：
- System.exit() 或 Runtime.halt()：直接终止 JVM 进程，不给字节码调度器留任何执行余地
- 线程被强制杀死（如 Thread.stop()，已废弃但仍有影响）或 JVM 崩溃（如 OutOfMemoryError 导致虚拟机无法继续工作）
- 守护线程被静默终止：当所有非守护线程结束，JVM 退出，正在运行的守护线程中的 finally 不会等待执行完毕
- 控制流卡死：try/catch 中陷入无限循环、死锁，或调用不可中断的阻塞操作（如未设超时的 socket.read()），程序根本走不到 finally 所在位置
所以，“保证执行”是有前提的
这个前提不是“语法写对了”，而是：程序仍在 JVM 的可控生命周期内，且控制流有机会抵达 finally 的字节码位置。它解决的是业务逻辑异常带来的不确定性，而不是操作系统级中断或人为强制退出这类外部干预。
正因如此，关键资源释放不能只依赖 finally ——更推荐用 try-with-resources（自动管理 Closeable 资源），它在语义上更明确，在异常传播处理上也更健壮。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
