finally块是最接近确定性执行的保障机制，它在try进入后、所有异常/返回路径下均执行，但遇system.exit()、jvm崩溃、线程强制终止或自身阻塞时失效；生产中应结合try-with-resources与超时兜底。

finally块在资源释放与清理中并非“绝对执行”，但它是**最接近确定性执行的保障机制**——关键不在“绝对”，而在“覆盖绝大多数意外路径”。理解它，要抓住两个维度：它一定做什么，以及它一定不做什么。

它一定在哪些情况下执行

只要控制流曾进入过对应的try块（哪怕只执行了一行），以下所有情形下finally都会运行：

• try正常结束（无异常）
• try抛出异常且被catch捕获 → catch执行完，再进finally
• try抛出异常但没被任何catch匹配 → finally先跑，再把异常向上抛
• try或catch里写了return、break、continue → finally在实际返回/跳转前执行
• catch里又抛新异常 → finally仍先执行，再继续冒泡新异常

它一定不执行的几种真实场景

这些不是边缘案例，而是工程中必须主动防御的边界：

• System.exit() 被调用：JVM进程立即终止，finally彻底跳过
• 线程被强制中断（如 Thread.stop()，虽已废弃但某些监控工具仍可能触发）
• JVM崩溃或被系统强杀（如 kill -9、OOM导致进程退出）
• finally自身陷入死循环或无限阻塞（比如等待一个永远不响应的锁）

为什么它比普通代码更可靠？

普通清理代码（比如写在try末尾或单独if判断后）会因以下常见路径而遗漏：

• try中间某行抛异常 → 后续清理语句直接跳过
• catch里处理完就return → 正常流程的清理没走
• 多个出口（不同return位置）→ 清理逻辑重复写或漏写

finally把清理逻辑“钉”在所有出口之前，由JVM字节码层面保障插入（现代JVM通过复制代码块实现），不依赖开发者对控制流的手动覆盖。

真正安全的资源释放，不能只靠finally

单靠finally是脆弱的。生产环境推荐组合策略：

• 优先用 try-with-resources（Java 7+）：自动管理AutoCloseable资源，close()失败还能抑制异常（suppressed），不掩盖主异常
• finally里只做“尽力而为”的清理：如fclose()失败只记日志，不throw；解锁失败打告警，不中断流程
• 关键资源配超时与兜底机制：数据库连接设query timeout，文件句柄配定时巡检，锁加watchdog线程