finally块不会执行。当try块内存在死循环时，线程无法退出try结构，控制流 never 到达finally；jvm仅在try或catch正常退出（含return、break、throw）或异常抛出后触发finally，而无限循环不满足“退出”条件。
Java中 try 代码块里出现死循环，finally 块确实不会执行——因为线程卡在循环里，根本没机会跳转到 finally。这不是 bug，而是 JVM 的正常行为：finally 只在 try 或 catch 正常退出（包括 return、break、throw）或异常抛出后才触发，而无限循环不满足“退出”条件。
确认是否真有死循环
别急着怀疑 JVM，先验证循环是否真的停不下来：
- 加日志：在循环体开头或关键位置打印时间戳或计数器，看输出是否持续刷屏且无终止迹象
- 用调试器挂起线程：在 IDE 中暂停程序，查看该线程堆栈，如果始终停留在某行 for/while 内，基本可判定为死循环
- 检查循环条件：常见陷阱包括变量未更新（i++ 写成 i+1）、浮点数精度比较（0.1 + 0.2 != 0.3）、对象状态未改变导致 while 条件恒为 true
区分“逻辑卡死”和“真正死循环”
有些情况看起来像死循环，实则不是：
Java Linux版
下载
Java Linux版下载入口，提供 Oracle JDK 26.0.2 官方 Linux 安装包、Java 环境配置、JDBC 数据库连接和 Java 服务端开发相关信息。
-
长时间阻塞操作：比如循环内调用
Thread.sleep(1000)或网络 I/O，它会暂停但终会继续，finally 最终能执行 -
线程被中断但未响应：循环里用了
while (!Thread.interrupted())却没处理中断，外部调用interrupt()后仍不退出——这时应检查是否漏了Thread.currentThread().isInterrupted()判断或忽略了InterruptedException - 锁竞争或资源等待：循环里反复尝试获取锁或数据库连接，若锁被永久占用或连接池耗尽，会一直等待——这不是死循环，而是同步问题
避免 finally 被绕过的安全写法
如果业务必须保证某些清理逻辑（如释放资源、记录状态）一定执行，不能依赖 finally 在死循环场景下生效：
- 把可能死循环的逻辑单独抽成方法，并在方法入口加超时控制或步数限制（例如最多执行 10000 次就强制 break）
- 使用
try-with-resources管理可关闭资源，它不依赖 finally 执行时机，只要 try 块开始执行就会注册自动关闭 - 对关键清理动作做双重保障：比如文件句柄除了 finally 关闭，也在循环中定期检测是否需提前释放；或用
Runtime.addShutdownHook做兜底（仅限 JVM 退出时）
用线程 dump 快速定位卡点
生产环境无法调试时，可通过线程快照抓取问题现场：
- Linux 下执行
jstack <pid> > thread.log</pid>，搜索RUNNABLE状态的线程，看其 stack trace 是否长期停在某个循环行 - JDK 自带
jcmd <pid> VM.native_memory summary</pid>辅助判断是否内存耗尽导致假性卡死 - 结合监控工具（如 Arthas）动态 watch 循环变量值变化，验证条件是否真的一成不变
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
