Java中finally块不执行的四种情况：一是System.exit()导致JVM立即终止；二是线程被Thread.stop()强杀或中断后阻塞未响应；三是JVM崩溃、系统kill-9或硬件故障等底层异常；四是finally内部抛出未处理异常或调用System.exit()。
在Java中，finally块几乎总是会执行，但“几乎”意味着存在少数明确的例外情况——这些场景下，finally确实不会被执行。理解这些边界条件，对编写健壮、可预测的资源清理逻辑至关重要。
JVM直接退出：System.exit()中断整个流程
当代码中调用System.exit(int status)时，JVM会立即终止当前进程，所有未完成的字节码（包括try-catch-finally中的finally）都会被跳过。
- 即使exit写在try或catch末尾，finally也不会触发
- 常见于某些框架的强制停机逻辑、测试用例中的异常退出，需特别警惕
- 替代方案：优先使用正常控制流返回，或通过Runtime.addShutdownHook做优雅关闭
线程被强制中断且未响应中断状态
如果执行try-finally的线程在进入finally前被Thread.stop()（已废弃但仍有遗留调用）或外部信号强杀，finally可能丢失。更现实的情况是：线程在finally之前陷入无限等待（如Object.wait()、LockSupport.park()），而此时线程被interrupt()，但代码未检查中断状态并提前退出，导致逻辑卡住——看似“没执行”，实则是阻塞而非跳过。
- Thread.stop()会立即抛出ThreadDeath异常，该异常不被普通catch捕获，且不保证finally执行
- 现代代码应避免stop()，改用协作式中断（interrupt + isInterrupted检查）
- 在finally中也应避免长时间阻塞操作
JVM崩溃或底层系统故障
例如发生OutOfMemoryError导致JVM核心崩溃、操作系统kill -9强杀进程、断电、硬件故障等。这类属于非Java可控的系统级异常，finally自然无法运行。
立即学习“Java免费学习笔记（深入）”；
- 这类情况无法通过编码完全规避，但可通过监控、内存调优、容器健康检查降低概率
- 关键资源（如数据库连接、文件句柄）建议配合外部管理机制，如连接池自动回收、文件系统watchdog
finally内部发生未处理的致命错误
如果finally块自身抛出异常（如NullPointerException）、错误（如StackOverflowError），或者调用了System.exit()，那么它“开始执行了”，但未能“完整执行完毕”。此时外层调用栈可能被截断，看起来像finally“没起作用”。
- 典型反模式：在finally里调用可能抛异常的方法却不处理，导致掩盖原始异常
- 最佳实践：finally中只做简单、确定成功的清理（如close()），且对close()调用加try-catch包裹
- Java 7+推荐使用try-with-resources，由编译器保障资源关闭，比手动finally更可靠
