try-catch-finally本身不会导致死锁，真正引发死锁的是其中执行的同步操作（如lock.lock()或synchronized），而非异常处理结构；死锁需满足循环等待等四个条件，常因加锁顺序不一致或finally中错误加锁而触发。
try-catch-finally 本身不会导致线程死锁，它只是异常处理语法结构，不具备资源竞争或锁获取能力。死锁发生在多线程并发访问共享资源且满足四个必要条件时，而 try-catch-finally 只是包裹代码的容器——真正引发死锁的，是其中执行的同步操作（如 synchronized 块、ReentrantLock.lock() 等），不是异常处理机制本身。
死锁可能出现在 try 或 catch 块内
当 try 或 catch 中包含加锁逻辑，且多个线程以不同顺序获取多个锁时，就可能形成循环等待：
- 线程 A 在 try 块中先锁 resourceA，再尝试锁 resourceB
- 线程 B 在 try 块中先锁 resourceB，再尝试锁 resourceA
- 若两者恰好交错执行（A 持 A 等 B，B 持 B 等 A），即刻陷入死锁
此时 finally 块尚未执行，程序已卡死；即使 finally 中有 unlock()，也根本没机会运行。
finally 块中的锁操作反而加剧风险
如果在 finally 中进行锁释放以外的加锁行为（例如错误地重入新锁、或调用含同步逻辑的清理方法），可能引入额外依赖链：
- 常见误写：在 finally 里调用另一个需持锁的方法，而该方法又依赖当前未释放的资源
- 更隐蔽的情况：使用可重入锁但未配对 unlock()，或在 finally 中执行阻塞 I/O（虽不直接锁，但可能间接持有锁并等待）
这类写法不违反语法，却把资源管理复杂度推高，增加死锁面。
异常抛出与锁释放的时序陷阱
try 块中发生异常后，控制流跳转到 catch 或 finally，但若锁未在异常路径中正确释放，会留下“悬挂锁”：
- 典型问题：只在 try 块末尾 unlock()，而异常发生在 unlock() 之前 → 锁永远不释放
- 正确做法：所有锁释放逻辑必须放在 finally 块中（或使用 try-with-resources）
- 注意：synchronized 是 JVM 自动释放的，但显式 Lock（如 ReentrantLock）必须手动 unlock()，且 unlock() 本身不应抛异常（否则可能跳过后续 unlock）
System.exit() 或 JVM 崩溃使 finally 失效，间接影响死锁诊断
虽然 finally 几乎总能执行（除 System.exit()、JVM crash 等极端情况），但这些场景会让资源清理中断：
- 若程序在死锁检测阶段调用 System.exit()，监控线程来不及输出堆栈，死锁现场丢失
- JVM 崩溃时，线程状态、锁持有关系全部丢失，无法复现和分析
- 这类失效不造成死锁，但让死锁变得不可见、难定位
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
