finally在System.exit、致命错误、Thread.stop()、kill-9时完全不执行；finally中return会无条件覆盖try/catch的返回值；try-with-resources比手动finally更可靠，因编译器自动处理异常抑制且无需判空。
在绝大多数情况下，finally 代码块会执行；但存在几个明确的例外，它们不是“偶尔不执行”，而是 JVM 规范定义的**合法跳过场景**——忽略这些，就可能在关键资源释放、日志落盘、状态回滚等地方埋下严重隐患。
哪些情况会导致 finally 完全不执行？
不是“异常没捕获所以 finally 不走”，而是 JVM 层面直接终止当前线程或进程，连 finally 的字节码都不会被调度：
-
System.exit(int)被调用（无论是否在try或catch中） - JVM 在执行
try或catch时遭遇致命错误（如OutOfMemoryError，且未被捕获） - 当前线程被强制中断（
Thread.stop()—— 已废弃但仍有遗留代码误用） - 操作系统 kill -9 强制终止进程（非 Java 层可控）
注意：return、break、continue、甚至抛出新异常，都不会阻止 finally 执行——这是最常被误解的一点。
finally 中的 return 会覆盖 try 或 catch 中的返回值吗？
会，而且是无条件覆盖。Java 规范规定：只要 finally 块中存在 return 语句，它就成为整个 try-catch-finally 结构的最终返回值，无论前面有没有 return。
立即学习“Java免费学习笔记（深入）”；
public static String test() {
try {
return "from try";
} catch (Exception e) {
return "from catch";
} finally {
return "from finally"; // ✅ 实际返回这个
}
}
更危险的是隐式覆盖：如果 finally 中有副作用（如修改对象字段、关闭流），但没有 return，则不会影响返回值；一旦加了 return，逻辑就彻底改变，极易引发难以追踪的 bug。
为什么 try-with-resources 比手动写 finally 关闭资源更可靠？
因为它的资源关闭逻辑由编译器生成并插入到 finally 的底层字节码中，且严格遵循“即使 close() 抛异常也不掩盖原始异常”的规则。而手写 finally 很容易写出这样的反模式：
FileInputStream fis = null;
try {
fis = new FileInputStream("a.txt");
return fis.read();
} catch (IOException e) {
throw new RuntimeException(e);
} finally {
if (fis != null) fis.close(); // ❌ 若 close() 抛 IOException，会掩盖上面的 RuntimeException
}
相比之下，try-with-resources 自动处理双重异常（suppressed exception），且无需判空、无需显式 try-catch 包裹 close()。
真正需要警惕的，从来不是“finally 会不会执行”，而是“它执行时上下文是否还完整”——比如线程已中断、堆内存耗尽、或 finally 本身又触发了不可恢复的错误。这些边界情况，在压力测试和故障注入中才容易暴露。
