waiting on condition 表示线程主动挂起等待条件成立，并非死锁，常见于 object.wait()、park() 或 nio 等场景，多数情况属正常阻塞，需结合调用栈与分布式锁上下文综合判断。
什么是 Waiting on condition 的真实含义
Waiting on condition 不代表死锁，而是线程在 Object.wait()、LockSupport.park() 或某些 NIO 操作中主动挂起，等待某个条件成立。JVM 线程 dump 里看到它，90% 的情况是正常阻塞（比如线程池空闲、Netty EventLoop 等待 IO），只有和特定调用栈结合时才可能指向分布式协调问题。
常见误判点：把 Waiting on condition 和 BLOCKED 混淆——后者是争抢 synchronized 锁失败，前者根本没在抢锁，只是“睡着了等通知”。
关键看堆栈顶部是否含以下模式：
-
java.lang.Object.wait(Native Method)+ 自定义锁类（如ZkLock、RedisLock） -
sun.misc.Unsafe.park(Native Method)+AbstractQueuedSynchronizer$ConditionObject.await() -
io.netty.channel.nio.SelectedSelectionKeySetSelector.select(...)—— 这个通常安全，不用管
如何从 jstack 输出里筛出可疑的分布式锁等待链
分布式死锁往往不是 JVM 层面的循环等待，而是多个服务节点在不同资源上按不同顺序加锁（例如：Service A 先锁 Redis key1 再查 ZK path2；Service B 反过来）。所以单看一个 jstack 没用，必须跨节点比对。
实操建议：
• 用 grep -A 10 "Waiting on condition" threaddump.log 提取所有相关线程段落
• 对每个段落，提取三要素：thread name、waiting on 后的对象哈希（如有）、最靠近顶部的业务类方法名（如 OrderService.process()）
• 重点标记那些在 tryLock()、acquire()、lockInterruptibly() 附近挂起的线程
• 如果发现两个节点的线程分别卡在 RedisLock.tryLock("order:123") 和 ZkLock.lock("/locks/payment:456")，且它们日志里都曾尝试获取对方持有的另一把锁，就高度可疑
为什么 jstack 本身无法直接报“分布式死锁”
JVM 只感知本地锁（synchronized、ReentrantLock），而 Redis/ZooKeeper/etcd 锁是应用层协议，jstack 看不到这些锁的持有关系。它只能告诉你：“这个线程在等一个 notify”，但不告诉你“notify 该由谁发”、“谁本该发却卡住了”。
性能影响上，Waiting on condition 线程不消耗 CPU，但若大量堆积，说明上游协调服务（如 Redis 响应慢、ZK session 超时重连）已出问题——这时候要查的是中间件监控，不是线程栈。
容易踩的坑：
- 用
jstack -l以为能显示显式锁信息 → 实际只对ReentrantLock有效，对 RedisLock 完全无用 - 看到 20 个线程都在
Waiting on condition就 panic → 可能只是流量低谷期线程池常规休眠 - 只分析一个节点的 dump → 分布式问题必须至少比对 2 个节点 + 协调服务（如 Redis 的
CLIENT LIST）
真正有效的定位动作：结合日志与外部状态
jstack 是起点，不是终点。下一步必须交叉验证：
• 查对应时间点的业务日志：搜索线程名（如 "pool-2-thread-7"）+ “lock”、“acquire”、“wait” 关键词，确认它卡在哪个锁 key 上
• 登录 Redis 执行 GET lock:order:123，看值是否为过期时间戳或客户端 ID；用 KEYS lock:* 快速扫一遍锁分布
• 查 ZooKeeper：用 echo stat | nc zk1 2181 看连接数，再用 ls /locks 看临时节点是否异常残留
• 如果用了 Curator，开启 CuratorFrameworkFactory.builder().connectionTimeoutMs(5000).retryPolicy(...) 的 debug 日志，它会打印每次重试和 watch 事件
分布式场景下，线程状态只是症状，真正要盯住的是锁资源的生命周期管理——谁创建、谁释放、超时是否设置、失败后是否回滚。jstack 里那个 Waiting on condition 行，只是告诉你“病人在这里等药”，但药在哪、谁该送、有没有被截胡，得去别处查。
