finally代码块执行时机解析

Java中finally代码块的执行时机常被误解为“仅在异常时触发”，实则它是在try/catch控制流离开前必然执行的收尾机制——无论是否发生异常、是否存在return/throw/break/continue，只要JVM未被强制终止（如System.exit()或崩溃），finally就一定会运行；其精妙之处在于return值先被暂存再执行finally，导致finally内return会覆盖结果、抛异常则吞掉原始异常；而现代Java更推荐用try-with-resources自动管理资源，仅在处理native资源、线程局部变量等特殊场景才需手动编写finally，既保障可靠性，又避免人为疏漏。

finally 块在 try 或 catch 执行完后、方法返回前执行

只要 JVM 没被强制终止（如 System.exit()），finally 块**一定会执行**，哪怕前面有 return、throw、break 或 continue。它不是“异常发生时才执行”，而是“控制流离开 try-catch 结构前的收尾动作”。

常见误解是认为 finally 只在抛异常时运行——其实正常流程也会进。

return 语句在 finally 之前求值，但实际返回被延迟

如果 try 或 catch 中有 return，JVM 会先计算返回值并暂存，然后执行 finally，最后才真正返回。这意味着：

• finally 里修改局部变量不影响已暂存的返回值
• finally 里再写 return 会覆盖原返回值（不推荐）
• finally 里抛出新异常，会吞掉原异常（原异常丢失）

public static String demo() {
    try {
        return "try";
    } finally {
        System.out.println("finally runs");
        // 下面这行会让最终返回 null，而不是 "try"
        // return "finally";
    }
}

finally 不执行的唯一情况：JVM 提前退出

以下情形会导致 finally **完全跳过**：

• System.exit(int) 被调用（进程立即终止）
• JVM 崩溃（如 native crash、OOM 导致无法调度）
• 线程被强制中断且未恢复（Thread.stop() 已废弃，但极端情况下仍可能绕过）
• 宿主环境杀进程（如 kill -9）

注意：return、throw、System.gc()、甚至无限循环都不会阻止 finally 执行。

资源清理优先用 try-with-resources，而非手动 finally

对于实现了 AutoCloseable 的资源（如 FileInputStream、Connection），应优先用 try-with-resources：

• 自动调用 close()，无需手写 finally
• 即使构造器抛异常，也能保证已成功创建的资源被关闭
• 多个资源按声明逆序关闭，语义更清晰

try (FileInputStream fis = new FileInputStream("a.txt");
     BufferedReader br = new BufferedReader(new InputStreamReader(fis))) {
    return br.readLine();
} // fis 和 br 自动 close，无需 finally

手写 finally 容易漏掉 null 判断或嵌套 try，而 try-with-resources 在编译期就约束了资源管理逻辑。

真正需要手写 finally 的场景很少，比如释放 native 资源、重置线程局部变量、记录日志等非 AutoCloseable 行为。

理论要掌握，实操不能落！以上关于《finally代码块执行时机解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！