finally块几乎总会在try或catch执行完毕后执行，用于确保资源清理；即使try中有return也会先记返回值再执行finally，但finally中return会覆盖原返回值；system.exit等极少数情况会导致finally不执行。
在Java中，finally块**几乎总会在try或catch执行完毕后执行**，无论是否发生异常、是否return、甚至是否抛出未捕获异常（除极少数情况外）。它的核心作用是确保关键清理逻辑（如关闭资源、释放锁）不被跳过。
finally的执行时机：在方法真正退出前
finally不是在try或catch“结束时”简单地追加执行，而是在控制流**即将离开当前try语句块作用域前**插入执行。这意味着：
- 即使
try中有return，也会先记下返回值，再执行finally，最后才真正返回； - 如果
catch中抛出新异常，finally仍会执行，之后才向上抛出新异常； - 若
finally中也有return或抛出异常，它会“覆盖”之前try/catch中的返回值或异常。
return语句与finally的交互细节
这是最容易混淆的点：return不是“立刻跳出方法”，而是分两步——先确定返回值，再执行finally，最后完成返回。
例如：
立即学习“Java免费学习笔记（深入）”；
public static int test() {
try {
return 1;
} finally {
System.out.println("finally executed");
return 2; // 这个return会覆盖try里的return 1
}
}
// 调用test()返回2，且打印"finally executed"
注意：finally中的return会直接终止方法，导致try中已准备好的返回值被丢弃。因此，避免在finally中写return或throw，否则可能掩盖真实逻辑和异常。
finally一定执行吗？例外情况有哪些
绝大多数情况下finally都会执行，但以下情况不会：
- JVM在try/catch执行期间直接退出，如调用
System.exit(0)； - 线程被强制中断且未恢复（极少见）；
- 发生致命错误（如
OutOfMemoryError），JVM无法正常调度； - 死循环或无限递归卡在try/catch内，程序未到达出口点。
日常开发中，只要没调System.exit或遇到严重JVM故障，finally就是可靠的。
现代写法建议：优先用try-with-resources
对于实现了AutoCloseable的资源（如FileInputStream、Connection），推荐用try-with-resources语法，它自动在隐式finally中调用close()，更简洁且不易出错：
try (FileInputStream fis = new FileInputStream("a.txt")) {
// 使用fis
} // 自动调用fis.close()，无需手动写finally
该语法本质仍是基于finally机制，但把资源管理逻辑标准化了，减少模板代码和遗漏风险。
