17370845950

会。finally块总会执行，即使try中有return；JVM先暂存return值，再执行finally，最后返回暂存值；若finally含return则覆盖原返回值，否则仅做清理。

try里有return，finally还会执行吗

会。只要finally块存在且未被System.exit()或JVM崩溃等极端情况中断，它就一定会执行——哪怕try块里写了return。

关键在于：不是“先return再finally”，而是“先暂存return值，再执行finally，最后返回那个被暂存的值”。这导致一个常见误解：以为finally里改了变量就能改变返回值——对基本类型和不可变对象（如String）无效；对可变对象（如StringBuilder、自定义对象）可能生效，但属于危险操作，不推荐依赖。

finally修改返回值的边界情况

只有当finally块自身也包含return语句时，它才会真正覆盖try或catch中的return。此时，try里的return会被完全丢弃，程序直接从finally返回。

• finally中无return：原return值被保留，finally仅做清理
• finally中有return：立即返回，跳过try/catch中已计算但未送出的返回值
• finally抛出异常：该异常会“吞掉”try中的return，调用方收到的是finally的异常

public static int test() {
    try {
        return 1;
    } finally {
        return 2; // 实际返回2，1被丢弃
    }
}

为什么不能在finally里写return

这不是语法错误，但属于严重逻辑陷阱：

• 掩盖真实退出路径：调用方无法区分是正常流程返回，还是finally强行截断
• 破坏异常传播：如果try抛了异常，finally的return会让异常彻底消失
• 违反直觉：多数开发者默认finally只做资源释放，突然返回值会引发维护困惑

Java官方文档明确建议：不要在finally中使用return、throw或break等转移控制流的语句。

更安全的替代写法

把清理逻辑和返回逻辑分离。需要“执行后返回”的场景，优先用显式变量承载结果，确保控制流清晰：

public static String readFile(String path) {
    BufferedReader reader = null;
    String content = null;
    try {
        reader = new BufferedReader(new FileReader(path));
        content = reader.readLine();
        return content; // 明确在此决定返回什么
    } catch (IOException e) {
        return null;
    } finally {
        if (reader != null) {
            try {
                reader.close(); // 只做清理，不碰return
            } catch (IOException ignored) {}
        }
    }
}

复杂点在于：return值的计算时机、finally对可变对象的副作用、以及JVM字节码层面的“暂存-执行-送出”三阶段模型。这些细节一旦忽略，调试时很容易误判执行顺序。