finally不一定执行。JVM强制终止（如System.exit或halt）、线程强杀或不可中断阻塞、系统崩溃及finally自身异常均会导致其失效或不完整。
不一定。finally块在绝大多数业务场景下都会执行，但它不是“绝对可靠”的保险丝——关键要看程序是否还有机会走到那一步。
JVM被强制终止：System.exit()和halt()
这是最典型也最容易被忽略的失效场景。只要在try或catch中调用System.exit(0)或Runtime.getRuntime().halt(0)，JVM会立即中止所有字节码执行，finally块根本不会被调度。
- System.exit()会触发关闭钩子（shutdown hooks），但不影响finally跳过
- Runtime.halt()更彻底：不运行钩子、不调用终结器，连finally都“来不及反应”
- 常见于测试用例强行退出、某些框架的紧急停机逻辑，需警惕
线程级中断与阻塞：没执行 ≠ 没触发
当执行try-finally的线程被强杀（如已废弃的Thread.stop()）或陷入不可中断等待（如未响应interrupt的Object.wait()、LockSupport.park()），finally可能“卡住”而非跳过。
- Thread.stop()抛出ThreadDeath异常，它不被普通catch捕获，且不保证finally执行
- 现代做法应使用协作式中断：调用interrupt() + 显式检查isInterrupted()
- finally里避免长时间IO或锁等待，否则资源释放可能延迟甚至失效
JVM或系统级崩溃：超出Java控制范围
这类情况无法通过编码预防，但必须纳入高可用设计考量：
立即学习“Java免费学习笔记（深入）”；
- OutOfMemoryError或StackOverflowError导致JVM核心崩溃
- 操作系统kill -9强杀进程、物理断电、硬件故障
- 此时不仅finally失效，整个应用状态都可能丢失
应对策略是引入外部保障机制：连接池自动回收空闲连接、文件系统watchdog定期扫描未关闭句柄、分布式锁设置超时自动释放。
finally自身出错：执行了，但没完成
这是线上最隐蔽的问题——finally看似运行了，实则中途崩溃或掩盖主异常：
- 在finally中调用close()时抛出IOException，却未捕获处理
- finally内发生NullPointerException或再次调用System.exit()
- try里抛业务异常A，finally又抛释放异常B → 外层只看到B，A被完全覆盖
正确写法是：在finally中做资源清理时，必须用独立try-catch包裹每个可能失败的操作，且不吞掉原始异常。
