死锁探测不依赖异常抛出，而是通过超时机制、状态监控和图算法检测环路来主动干预；核心是设定等待边界，唤醒后重检条件并决策，而非被动等待。
死锁探测不是靠“抛异常”来触发的，而是通过主动引入超时边界、状态监控和外部干预，让线程不陷入无限等待。核心思路是：**不让等待真正“无限”，而是在可控时间后强制退出并做决策**。
条件变量必须配合超时等待
直接调用 wait()（如 Java 的 Object.wait()、Python 的 threading.Condition.wait()、C++ 的 cond_var.wait()）会一直阻塞，直到被通知——但若通知永远不来，就卡死。正确做法是始终使用带超时的变体：
- Java：
wait(long timeout)或LockSupport.parkNanos()配合自旋检查 - Python：
cond.wait(timeout=3.0)，返回False表示超时，需手动判断条件是否真成立 - Go：
sync.Cond本身不支持超时，必须用time.AfterFunc+Broadcast()或改用select+time.After
关键点：超时只是“唤醒”，不是“解决”。唤醒后必须重新加锁、重检业务条件，再决定是继续等待、重试，还是报错/降级。
定时扫描+依赖图检测（适用于长期运行服务）
在中间件、数据库连接池或自研同步框架中，可构建轻量级死锁探测器：
- 为每个锁维护持有者线程 ID 和等待者队列
- 每 5–10 秒遍历一次锁关系，构建有向图：A → B 表示“线程 A 等待线程 B 持有的锁”
- 用 DFS 或 Floyd 判环算法检测是否存在循环路径（如 A→B→C→A）
- 一旦发现环，主动中断其中一个等待线程（如抛
InterruptedException或调用Thread.interrupt()），并记录告警日志
注意：该机制开销可控，但不能替代编码规范；它属于兜底手段，不是第一道防线。
MySQL 等系统级超时是天然探测入口
数据库层面的锁等待超时（如 MySQL 的 innodb_lock_wait_timeout=50）本身就是一种被动死锁探测信号：
- 当应用层收到
LockWaitTimeoutException，说明至少有一个事务已卡住超过 50 秒 - 结合
SHOW ENGINE INNODB STATUS或INNODB_TRX视图，能定位到持锁与等锁双方 - 此时可触发熔断：暂停该业务流、切换读副本、或退化为异步补偿
这类超时不是“异常处理”的终点，而是诊断起点——它暴露了代码中资源获取顺序不合理、事务粒度太粗等问题。
避免把超时当成万能解药
超时值设得太短，会导致频繁假失败；设得太长，又失去探测意义。合理设定需结合：
- 业务 SLA：支付类操作通常 ≤ 2 秒，报表导出可放宽至 30 秒
- 依赖链耗时：若下游 RPC 平均耗时 800ms，本地锁等待超时建议 ≥ 2s
- 重试策略：超时后是否重试？最多几次？间隔是否递增？
更重要的是，超时本身不消除死锁成因。它只缓解症状。根治仍需统一锁序、减少嵌套锁、用 tryLock 设置超时、或改用无锁数据结构。
