finally块总在try/catch执行完、方法返回前执行（JVM未强制终止时），即使有return/throw/break/continue；return值先暂存再执行finally，其中return会覆盖原值，抛异常则吞掉原异常；唯一不执行是JVM提前退出。
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 **完全跳过**：
立即学习“Java免费学习笔记（深入）”；
-
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 行为。
