finally 块无论是否抛出异常都会执行(除非 JVM 退出);即使 try 或 catch 中有 return,也会暂存返回值,先执行 finally 再返回,若 finally 也有 return 则覆盖原值。

try-catch-finally 的执行顺序到底是什么
无论是否抛出异常,finally 块一定会执行(除非 JVM 直接退出,比如调用 System.exit())。关键在于:即使 catch 中有 return,finally 也会在方法真正返回前执行。
常见误解是“catch 返回了,finally 就不走了”,其实不然。JVM 会暂存 return 的值,先执行 finally,再返回——除非 finally 自己也写了 return,那就直接覆盖原返回值。
-
try正常结束 → 跳过catch,执行finally,再继续后续代码 -
try抛出异常且被catch捕获 → 执行catch,再执行finally,再继续后续代码 -
try或catch中有return→ 暂存返回值,强制进入finally,执行完再返回(若finally也有return,则以它的为准) -
finally中抛出异常 → 会压制try或catch中的异常,外部看到的是finally的异常
finally 里写 return 会带来什么后果
这是最容易踩坑的地方:finally 中的 return 会吞噬掉 try 或 catch 中的返回值甚至异常,导致逻辑完全偏离预期。
例如下面这段代码:
立即学习“Java免费学习笔记(深入)”;
public static String test() {
try {
return "from try";
} catch (Exception e) {
return "from catch";
} finally {
return "from finally"; // ⚠️ 这行让前两个 return 全部失效
}
}
调用 test() 永远返回 "from finally",哪怕 try 里没异常、也没被中断。更危险的是,如果 finally 抛异常(比如空指针),还会把原始业务异常彻底掩盖。
- 永远不要在
finally中写return - 资源清理(如
close())可以放finally,但不要在里面控制流程或返回值 - 若真需要修改返回值,应在
try/catch中完成,finally只做收尾
try-with-resources 能否替代 finally 做资源关闭
可以,而且更安全。Java 7 引入的 try-with-resources 会在语句结束时自动调用 AutoCloseable.close(),无需手写 finally。
但它只适用于实现了 AutoCloseable 接口的对象(如 FileInputStream、BufferedReader),且关闭顺序与声明顺序相反(后声明的先关闭)。
- 必须在
try括号内声明并初始化资源,不能是已存在的变量引用 - 多个资源用分号隔开,每个都会被自动关闭
- 如果
close()抛异常,它会被抑制(suppressed),可通过Throwable.getSuppressed()获取,主异常仍正常抛出 - 传统
finally仍适用于非AutoCloseable类型的清理逻辑(如解锁、重置状态等)
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedReader br = new BufferedReader(new InputStreamReader(fis))) {
return br.readLine();
} // fis 和 br 在此处自动 close()
catch 多个异常时的顺序和兼容性要注意什么
多个 catch 必须按“子类在前、父类在后”的顺序排列,否则编译失败。因为 JVM 匹配异常时是按书写顺序从上到下找第一个能匹配的块。
例如 IOException 是 Exception 的子类,如果把 Exception 放前面,后面的 IOException 永远不会被执行。
- Java 7+ 支持多异常捕获语法:
catch (IOException | SQLException e),但要求这些异常互不继承 - 若需对不同异常做差异化处理,必须拆成独立
catch块,并严格按继承层级倒序排列 - 注意
RuntimeException及其子类(如NullPointerException)属于未检查异常,不强制要求catch,但一旦出现在try中,仍可被捕获
最常被忽略的一点:finally 的执行不受 catch 是否存在影响——哪怕你只写 try-finally,没有 catch,finally 依然保证执行。这恰恰是做资源释放最稳妥的方式之一。










