Java中finally块几乎总能执行，但存在四种例外：JVM强制终止（如System.exit()）、线程被强制中断（如kill-9）、JVM崩溃或致命错误、以及try/catch内死循环或无限阻塞导致控制流无法到达finally。
Java 中的 finally 块**几乎总能执行**，但确实存在几种明确的特殊情况会导致它**不执行**。理解这些边界情况，对编写健壮、可预测的资源清理逻辑至关重要。
JVM 强制终止（System.exit()）
当代码中调用 System.exit(int status) 时，JVM 会立即终止当前进程，所有正在执行的线程（包括 try-catch-finally 的后续流程）都会被强行中断。
此时 finally 完全不会运行 —— 即使它写在 return 语句之后、即使异常已被捕获。
- 常见于命令行工具或测试中主动退出
- 注意：Runtime.getRuntime().exit() 效果相同
- 替代方案：尽量用异常抛出或正常返回代替 exit()
线程被强制中断（Thread.stop() 或 kill -9）
Thread.stop() 是已废弃且危险的方法，它会立即停止目标线程，不保证栈展开，因此 finally 不会被触发。
立即学习“Java免费学习笔记（深入）”；
更现实的情况是：操作系统层面用 kill -9（SIGKILL） 杀死 JVM 进程，此时整个进程瞬间消失，finally 当然无法执行。
- stop() 在现代 Java 中应绝对避免
- SIGKILL 无法被 Java 捕获或响应，属于系统级不可恢复中断
JVM 崩溃或致命错误
发生严重底层错误时，例如：
- 本地代码（JNI）导致段错误（Segmentation Fault）
- OutOfMemoryError 严重到无法分配任何对象（如 metaspace 耗尽且无法回收）
- JVM 内部断言失败或崩溃（如 HotSpot bug）
这类问题会让 JVM 失去控制权，程序直接退出，finally 无机会执行。
死循环或无限阻塞在 try/catch 中
这不是“finally 不执行”，而是**程序卡在了 try 或 catch 里，根本走不到 finally**。
例如：
- try 块末尾有 while(true) {}
- catch 中调用了 Object.wait() 且无人 notify
- 锁竞争导致永久阻塞（如 synchronized 死锁）
这种情况下 finally 语法上“应该执行”，但因控制流未到达，实际永不执行 —— 属于逻辑问题，而非 JVM 规则例外。
基本上就这些。只要 JVM 正常运行、线程自然结束（return / throw / 正常落空）、没被外力强杀，finally 就一定执行。写资源清理时，优先考虑 try-with-resources；若必须手动释放，务必警惕 System.exit 和本地崩溃风险。
