finally在return之后仍会执行，JVM先暂存return值，再执行finally，最后返回暂存值；若finally中也有return则覆盖原值，若抛异常则吞掉原异常，修改引用对象字段会影响返回结果。
finally 在 return 之后还执行吗
执行。只要 try 或 catch 中进入了可执行路径（哪怕写了 return），且 JVM 没崩溃、没调用 System.exit()、没断电，finally 就一定会执行——它在 return 表达式求值之后、真正退出方法之前插入执行。
常见误解是“return 一写，方法立刻结束”，其实 JVM 会先把 return 的值暂存，再进 finally，最后才把暂存的值真正返回。所以：
- 如果
finally里也有return，它会覆盖try/catch中的返回值 - 如果
finally抛出异常，它会吞掉try/catch中的返回或异常（原异常丢失） - 若
finally中修改了引用对象的字段，会影响返回结果（因为是同一对象）
finally 不执行的几种真实情况
不是“几乎总是执行”，而是“在绝大多数正常流程中执行”。真正跳过 finally 的场景非常有限，但容易被忽略：
- JVM 进程被强制终止：比如外部执行
kill -9，或代码中调用Runtime.getRuntime().exit() -
try或catch块中发生了ThreadDeath（如stop()已废弃但仍有遗留调用） - 线程被中断且未恢复执行（极少见，多见于底层 JNI 或信号处理异常）
-
try块还没开始执行就发生栈溢出（StackOverflowError）或内存耗尽（OutOfMemoryError），此时连try都没进入，自然不走finally
注意：return、break、continue、普通异常抛出，全部不影响 finally 执行。
立即学习“Java免费学习笔记（深入）”；
资源清理时为什么不能只靠 finally
finally 是手动清理的兜底手段，但不是最安全的选择。问题在于它不强制检查资源状态，也不处理嵌套异常：
- 如果
try中打开多个资源（如文件流 + 数据库连接），finally里要挨个判空关闭，代码易错且冗长 - 若第一个
close()抛异常，后续close()可能被跳过（除非每个都包try-catch） -
finally无法自动抑制异常（suppressed exception），而try-with-resources会把次要异常作为 suppressed 添加到主异常上
推荐优先用 try-with-resources（要求资源实现 AutoCloseable），finally 仅用于不满足该接口的清理逻辑，比如释放本地内存、取消定时任务、解锁 ReentrantLock 等。
finally 中修改返回值的真实行为
基本类型返回值会被覆盖，引用类型返回值的内容可被修改，但指向不会变。看这个例子：
public static StringBuilder foo() {
StringBuilder sb = new StringBuilder("hello");
try {
return sb;
} finally {
sb.append(" world"); // ✅ 生效：返回对象内容变成 "hello world"
// sb = new StringBuilder("nope"); // ❌ 无效：改变的是局部变量 sb，不影响已确定的返回引用
}
}
再看基本类型：
public static int bar() {
try {
return 1;
} finally {
return 2; // ✅ 覆盖原返回值，实际返回 2
}
}
这种写法虽然合法，但极易引发维护困惑，应避免在 finally 中写 return 或重新赋值返回变量。
最常被忽视的一点：finally 的语义是「确保执行」，不是「确保不干扰逻辑」。它的存在本身就会改变控制流和异常传播路径，写的时候得像写临界区一样谨慎。
