1. 为什么我们最终还是离不开Condition如果你在Java并发这条路上走了几年大概率会有这样的体会synchronizedwait/notify应付简单场景绰绰有余可一旦涉及多个等待条件、超时控制、或者需要精准唤醒某一类线程时直接上手LockCondition往往才是正解。但很多人用Condition只是停留在会用的层面——知道await()和signal()大致是挂起和唤醒却说不清这两个方法在 AQS 里到底做了什么事更别提遇到signal丢唤醒、条件谓词被破坏这类诡异问题时怎么调试。这篇文章是系列第三篇前两篇分别讲了Lock的基本用法和 AQS 同步队列的运作机制。这一篇我打算把Condition的await和signal彻底掰开揉碎从源码到实战从设计意图到踩坑记录一次性讲透。先给不太熟的读者交个底Condition是java.util.concurrent.locks包下的接口典型的用法是配合ReentrantLock一起出现。它提供了比wait/notify更细粒度的等待/通知能力——你可以在同一个锁上建立多个条件队列比如缓冲区非空和缓冲区未满是两个独立条件生产者只等未满消费者只等非空互不干扰。而synchronized的wait/notify只有一个隐式条件队列压根做不到这种精准唤醒。从设计层面看Condition的底层实现是 AQS 内部的ConditionObject它维护了一条独立于同步队列的条件等待队列。await的本质是把当前线程包装成节点挂到条件队列上并释放锁signal的本质是把条件队列里的节点重新转移回同步队列等它重新拿到锁后再继续执行。一句话概括就是await 是让出锁 等待条件signal 是标记条件可能满足 唤醒等待者但中间涉及的节点状态流转、中断处理、队列转移每一个环节都有坑。接下来我会从接口设计的初衷开始讲重点放在源码执行链路的逐步拆解上然后结合一个真实的多条件队列案例最后把我在项目中踩过的几个典型问题拿出来复盘。无论你是准备面试还是要在生产环境里写出可靠的并发代码这篇应该都能给你一些参考。2. 从 wait/notify 到 Condition接口设计解决了的三个痛点2.1 一个隐式等待队列导致的惊群与误唤醒聊Condition之前有必要先把wait/notify的局限性摊开来讲。synchronized的监视器模型里一个锁只对应一个隐式条件队列。这意味着当多个线程因为不同原因在同一把锁上等待时一旦某个线程调用了notifyAll()所有等待线程都会被唤醒然后它们会竞争锁依次判断自己的条件是否真的满足了。听起来好像没啥大问题但在高并发场景下这种一刀切的唤醒方式会引发两个连锁反应。第一是惊群效应大量线程被无效唤醒白白经历一轮抢占锁 - 检查条件 - 不满足 - 再次挂起的完整循环CPU 和锁竞争的开销直线上升。第二是更隐蔽的正确性问题假设缓冲区只有一个空位生产者和消费者同时在等消费者被唤醒后发现自己等的是非空但此时缓冲区其实是空的它必须再次wait而真正的生产者可能因为锁被消费者抢走而迟迟无法进入临界区造成活锁式的空转。Condition的出现就是为了解决这个结构性问题。它允许开发者在同一把锁上注册多个条件队列每个队列对应一个独立的等待谓词。还是以缓冲区为例你可以创建两个Condition一个是notFull让生产者等有空位另一个是notEmpty让消费者等有数据。生产者入队后signal(notEmpty)消费者出队后signal(notFull)各唤醒各的互不打扰。2.2 中断响应与超时控制可打断的等待才有工程价值wait()方法有一个非常恼人的特性它只支持不可中断地等待。也就是说线程进入wait()之后除了被notify/notifyAll唤醒唯一能打断它的方式是interrupt()但这会直接抛出InterruptedException而且必须在重新获取锁之后才能抛出。这在很多需要优雅停机的场景里很尴尬——你没法说等最多 3 秒超时就算了。Condition接口则提供了三种带时间参数的方法awaitNanos(long nanosTimeout)、await(long time, TimeUnit unit)、awaitUntil(Date deadline)。它们都支持超时后自动返回也支持在等待期间响应中断。这个能力在实际项目中几乎是刚需——比如 RPC 调用里等待响应总不能让线程无限期挂在那儿。2.3 公平锁下的队列行为一致性Condition还有一个容易被忽略的优势它是 AQS 的一部分天然继承了ReentrantLock的公平性语义。公平锁模式下signal唤醒的线程会按照 FIFO 顺序进入同步队列不会出现后唤醒的插队先跑这种情况。而synchronized的notify唤醒哪个线程是 JVM 实现细节没有公平性保证。对于某些需要严格顺序控制的场景比如分布式锁续期、任务调度器这个差异是实实在在的。提示Condition必须与Lock绑定使用condition.await()必须在lock.lock()和lock.unlock()之间调用否则会抛出IllegalMonitorStateException。这一点和wait()必须在synchronized块内调用是同一个道理。3. await 方法内部发生了什么节点入队、锁释放与状态挂起的三步曲3.1 前置知识AQS 里到底有几条队列要真正看懂await的源码脑子里必须先建立两条队列的模型。AQS 内部维护了两个核心数据结构同步队列Sync Queue所有竞争锁但暂时没抢到的线程会被封装成节点挂在这个 CLH 队列上等待被唤醒后重新尝试获取锁。条件队列Condition Queue调用condition.await()的线程会被封装成节点挂在这个条件对应的单向链表上等待被signal转移。这两条队列各自独立节点类型都是 AQS 内部的Node但状态字段的取值不同。同步队列里的节点状态可能是SIGNAL-1、CANCELLED1等条件队列里的节点状态为CONDITION-2表示它正在条件队列中等待。3.2 await 方法的三步核心流程我们先看AbstractQueuedSynchronizer.ConditionObject.await()的核心骨架忽略中断处理和细节判断后的逻辑是这样的public final void await() throws InterruptedException { // 1. 如果中断标志已置位直接抛异常 if (Thread.interrupted()) throw new InterruptedException(); // 2. 将当前线程封装成 Node状态设为 CONDITION加入条件队列末尾 Node node addConditionWaiter(); // 3. 释放当前线程持有的锁并保存释放前的锁状态 int savedState fullyRelease(node); int interruptMode 0; // 4. 自旋检查当前节点是否已被转移到同步队列 while (!isOnSyncQueue(node)) { // 5. 未转移则阻塞挂起 LockSupport.park(this); // 6. 被唤醒后检查中断状态 if ((interruptMode checkInterruptWhileWaiting(node)) ! 0) break; } // 7. 重新竞争锁并处理中断 if (acquireQueued(node, savedState) interruptMode ! THROW_IE) interruptMode REINTERRUPT; // 8. 清理条件队列中已取消的节点 if (node.nextWaiter ! null) unlinkCancelledWaiters(); // 9. 根据中断模式抛出异常或补设中断标志 if (interruptMode ! 0) reportInterruptAfterWait(interruptMode); }我把这段源码翻译成大白话await干的事情就是三件第一件把自己挂到条件队列上。这一步没有任何锁竞争因为线程此刻还持有锁是临界区内的操作。addConditionWaiter()会创建一个状态为CONDITION的节点追加到条件队列的尾部。注意条件队列是一个单向链表通过node.nextWaiter指针串联和同步队列的双向链表结构不同。第二件彻底释放锁。fullyRelease(node)会调用release(savedState)把当前线程持有的锁完全释放掉。这里的savedState是重入次数——如果当前线程对同一把锁重入了 3 次savedState就是 3释放时会把持有计数清零持有数减到 0 后锁才算真正释放。这一步非常关键它保证了其他线程能够进入临界区去产生条件满足的事件否则就会死锁。第三件自旋等待被转移到同步队列。while (!isOnSyncQueue(node))这个循环是整个await的核心。isOnSyncQueue检查当前节点是否已经从条件队列转移到了同步队列。如果没有线程就调用LockSupport.park(this)原地挂起直到被signal唤醒或者被中断。3.3 为什么 await 之后的代码必须放在循环里这个节点转移的检查过程背后藏着一个初学者最容易踩的坑虚假唤醒spurious wakeup。LockSupport.park的规范里明确说明它可能会在没有收到 unpark 信号的情况下自行返回。也就是说线程可能什么都没等到就莫名其妙地从park里醒过来了。如果await的代码实现成醒来就往下走那么线程可能在条件并不满足的情况下继续执行临界区操作造成数据竞争。所以源码里才用了while循环重新检查isOnSyncQueue(node)——如果节点还在条件队列里说明条件没被满足线程需要继续park。这也是为什么官方文档反复强调await应该在循环里调用循环条件就是你的等待谓词。看下面这个标准写法lock.lock(); try { while (!conditionSatisfied()) { condition.await(); } // 条件满足继续执行业务逻辑 } finally { lock.unlock(); }await返回后外层的while还会再检查一次conditionSatisfied()只有返回 true 才会往下走这就是双重保险。4. signal 到底做了哪些事条件队列到同步队列的节点转移4.1 从 doSignal 看唤醒的第一个节点讲完awaitsignal的逻辑就顺理成章了。signal()的作用是唤醒条件队列中等待时间最长的那个线程源码里的入口是doSignalpublic final void signal() { // 检查当前线程是否持有锁 if (!isHeldExclusively()) throw new IllegalMonitorStateException(); Node first firstWaiter; if (first ! null) doSignal(first); }doSignal做的事情是从条件队列头节点开始依次尝试将它转移到同步队列直到转移成功或者队列为空。为什么是依次尝试因为头节点可能已经被中断取消了——线程在等待期间收到了中断信号节点状态不再是CONDITION这种节点会被跳过继续处理下一个。转移操作的核心是transferForSignal方法final boolean transferForSignal(Node node) { // CAS 将节点状态从 CONDITION 改为 0 if (!compareAndSetWaitStatus(node, Node.CONDITION, 0)) return false; // 把节点加入同步队列返回前驱节点 Node p enq(node); int ws p.waitStatus; // 如果前驱节点已取消或者 CAS 设置前驱节点为 SIGNAL 失败 // 直接唤醒当前线程 if (ws 0 || !compareAndSetWaitStatus(p, Node.SIGNAL, thread)) LockSupport.unpark(node.thread); return true; }这里有两个细节值得展开。细节一为什么要把节点状态从CONDITION改成 0因为节点一旦进入同步队列它就参与了锁竞争不再属于条件队列。状态改为 0初始状态是让它在同步队列里以普通节点的身份参与排队后续acquireQueued会根据前驱节点的状态来决定是否挂起。细节二为什么转移后还要判断前驱节点状态必要时直接unpark因为enq(node)将节点放入同步队列后当前线程还在await的park状态里它需要等前驱节点释放锁后才能被唤醒。但如果前驱节点的状态是CANCELLED表示前驱线程已经被取消不会再释放锁了或者尝试把前驱节点标记为SIGNAL失败那就没有人会在将来唤醒当前线程了。所以这里做了一个兜底操作直接unpark唤醒当前线程让它自己去同步队列里重新竞争锁。这也解释了为什么signal并不保证唤醒后立刻执行——它只是把节点从条件队列挪到同步队列最终还是要排队等锁。4.2 signalAll 的循环转移逻辑signalAll()的实现思路更直接public final void signalAll() { if (!isHeldExclusively()) throw new IllegalMonitorStateException(); Node first firstWaiter; if (first ! null) doSignalAll(first); }doSignalAll会遍历整条条件队列把所有节点都转移到同步队列private void doSignalAll(Node first) { lastWaiter firstWaiter null; do { Node next first.nextWaiter; first.nextWaiter null; transferForSignal(first); first next; } while (first ! null); }这里注意一点signalAll并不保证所有被唤醒的线程都能立即继续执行更不保证它们都拿到了锁。它只是把条件队列清空、节点全部入同步队列排队而已。最终谁能先跑取决于同步队列里的排队顺序和锁的竞争情况。如果用的是公平锁那么先入队的线程会先获得锁顺序是可控的如果是非公平锁一切皆有可能。4.3 signal 与 await 的锁关系为什么必须在持有锁时调用上一节提到signal()的第一步就是检查isHeldExclusively()如果当前线程不持有锁直接抛IllegalMonitorStateException。这个设计不是随意加的限制它背后有一个内存可见性的考量。假设线程 A 调用await后释放了锁线程 B 在锁内修改了共享状态并调用signal。如果允许 B 在不持有锁的情况下signal那就意味着 B 修改的共享变量与signal之间没有建立 happens-before 关系A 被唤醒后看到的共享状态可能是过期的。而强制 B 持有锁再signalA 释放锁 - B 获取锁 - B 修改状态 - B 释放锁 - A 重新获取锁这条链路上每一步都有 volatile 变量的读写AQS 的state就是 volatile 的从而保证了 A 能看到 B 做的所有修改。所以那句signal 也要在 lock 内调用不是文档建议是必须遵守的规则。违反它不只是抛异常的问题更深层的危害在于可能破坏内存可见性让被唤醒的线程看到脏数据。5. 多条件队列实战有限缓冲区模型重构5.1 用两个 Condition 精确控制生产与消费理论说了一大堆不如带一个完整的例子跑一遍。我用一个经典的有界阻塞队列来演示多条件队列的用法。它的核心是维护一个固定容量的数组用两个条件变量分别管理缓冲区非空消费者等待条件和缓冲区未满生产者等待条件。package com.example.concurrent; import java.util.concurrent.locks.Condition; import java.util.concurrent.locks.ReentrantLock; public class BoundedBufferT { private final Object[] items; private int count; private int putIndex; private int takeIndex; private final ReentrantLock lock new ReentrantLock(); private final Condition notFull lock.newCondition(); private final Condition notEmpty lock.newCondition(); public BoundedBuffer(int capacity) { if (capacity 0) { throw new IllegalArgumentException(capacity must be positive); } items new Object[capacity]; } public void put(T item) throws InterruptedException { lock.lock(); try { // 条件谓词缓冲区不能满 while (count items.length) { notFull.await(); } items[putIndex] item; putIndex (putIndex 1) % items.length; count; // 唤醒一个等待非空条件的消费者 notEmpty.signal(); } finally { lock.unlock(); } } SuppressWarnings(unchecked) public T take() throws InterruptedException { lock.lock(); try { // 条件谓词缓冲区不能空 while (count 0) { notEmpty.await(); } T item (T) items[takeIndex]; items[takeIndex] null; takeIndex (takeIndex 1) % items.length; count--; // 唤醒一个等待未满条件的生产者 notFull.signal(); } finally { lock.unlock(); } } }这个实现里最值得留意的是三个设计决策。决策一为什么用while而不是if包裹await前面讲过一是防虚假唤醒二是防多个生产者同时被唤醒后缓冲区实际只剩一个空位这一类的竞争条件。用while每次醒来都重新检查谓词确保只有条件真正满足时才往下走。决策二为什么用signal()而不是signalAll()因为每次put只往缓冲区里放了一个元素最多也只能让一个消费者继续执行。用signalAll()会把所有消费者都唤醒然后它们又会在while (count 0)处排队检查大多数会被再次挂起纯属浪费。反过来也一样每次take只腾出一个空位只需要唤醒一个生产者。这就是多条件队列的精准唤醒优势。决策三put里为什么用notEmpty.signal()而不是notFull.signal()因为put改变的是缓冲区非空这个条件——放进去一个元素消费者等待的条件发生了变化。同理take改变的是缓冲区未满这个条件所以唤醒的是notFull。唤醒错了对象会让本该被唤醒的线程继续沉睡而醒来的线程条件并不满足白白空转。5.2 从一锁一等待队列到一锁多等待队列的思维转变很多人第一次接触多条件队列时会困惑synchronized一个锁就一个队列用wait/notify不也能实现有界缓冲区吗为什么要引入两个Condition的复杂度我可以用synchronized版本试了一下很快发现痛点在哪。当生产者和消费者共用同一个等待队列时notifyAll的风险是可能把应该被唤醒的线程和不应该被唤醒的线程一起叫起来。比如缓冲区满了一个生产者wait了同时缓冲区是空的两个消费者也wait了。此时消费者拿走一个元素后notifyAll结果是三个线程全醒了但缓冲区只有一个空位最终只有一个生产者能入队另外两个线程检查完谓词后又得重新挂起。这在负载低的时候看不出问题但在高并发下无效唤醒会放大锁竞争线程频繁在RUNNABLE和WAITING之间切换上下文切换开销陡增。而多条件队列的设计从根源上避开了这个问题notEmpty.signal()只唤醒一个消费者notFull.signal()只唤醒一个生产者每个线程只会在自己等待的条件上被唤醒。5.3 公平性配置对 Condition 唤醒顺序的影响上面这个BoundedBuffer在公平锁和非公平锁下的行为略有差异这个差异值得展开聊一下。如果用new ReentrantLock(true)创建公平锁那么signal转移节点到同步队列后节点的排队顺序严格遵循 FIFO先await的线程会先被唤醒先被唤醒的线程会先拿到锁。这在高并发场景下能避免线程饥饿但代价是吞吐量可能下降因为线程被唤醒到真正执行之间需要经历完整的排队过程。非公平锁则允许新来的线程插队抢锁吞吐量更高但某些等待较久的线程可能一直抢不到锁极端情况下会发生饥饿。具体选哪种取决于业务需求。如果对执行顺序有强要求选公平锁如果更关心吞吐量选非公平锁但要做好某些线程等待时间较长的心理准备。6. await 与 signal 的几个高频陷阱从死锁到信号丢失6.1 陷阱一signal 被吞掉——条件谓词真的满足了吗这是并发编程里最经典的坑之一官方叫 lost wakeup丢失唤醒。场景通常是这样的// 错误示例 public void put(T item) throws InterruptedException { lock.lock(); try { if (count items.length) { notFull.await(); } // ...入队操作 notEmpty.signal(); } finally { lock.unlock(); } }看到问题了吗if换成while的瞬间条件谓词只检查了一次。假设线程 A 和线程 B 同时执行put缓冲区只剩一个空位。A 先拿到锁发现未满入队成功后释放锁B 拿到锁发现已满进入await挂起。A 释放锁后如果有消费者 C 拿走了一个元素并调用notFull.signal()B 被唤醒。此时 B 醒来后执行了if (count items.length)的判断发现有空位了于是准备入队。这个流程看似没问题。但如果秦 C 拿走元素后还没有执行signal()之前B 正好被虚假唤醒执行了if检查——此时缓冲区还是满的B 会跳过await直接入队结果覆盖了未读数据。更隐蔽的场景是消费者 C 执行take后缓冲区从满变成非满调用notFull.signal()但此时 B 还没调用await还在if判断后的代码里于是signal只唤醒了一个还没开始等待的线程等效于信号丢失。之后 B 再调await就没有人能唤醒它了直接死锁。正确做法就是我上面代码里写的while (count items.length)循环检查每次醒来重新验证谓词。这个规则不仅仅是 Condition 的规定wait/notify、CountDownLatch.await、BlockingQueue.put背后的逻辑全是这个套路。6.2 陷阱二await 期间线程被中断会怎样很多人在await里被中断后一脸懵明明我写的是InterruptedException的捕获代码为什么程序还是挂在那里不动了这里要分两种情况看。第一种情况线程在park挂起期间收到中断信号await会检测到中断退出等待循环最终抛出InterruptedException。第二种情况线程在signal转移节点后、重新竞争锁的排队期间收到中断信号——此时节点已经在同步队列里了await不会立刻抛出异常而是会先完成锁的获取再根据中断模式决定是抛出InterruptedException还是只补设中断标志位。源码里的interruptMode有三种取值REINTERRUPT重新设置中断标志、THROW_IE抛出异常、0未中断。这个设计其实是 JDK 在响应中断和保证锁获取完成之间做的一个折中——如果线程在等锁期间被中断强行中断不仅可能导致锁状态不一致还可能让临界区代码在没有正确上锁的情况下执行所以必须先拿到锁再响应中断。实战中的启发是捕获到InterruptedException后不要简单地e.printStackTrace()就完事。如果当前任务需要继续执行应该重新设置中断标志让上层调用者知道发生了中断如果任务必须终止则要确保锁和资源的正确释放。6.3 陷阱三awaitNanos 返回值——剩余时间不够时怎么办awaitNanos(long nanosTimeout)这个方法的返回值是剩余等待时间而不是是否超时。很多人忽略了这个返回值把超时判断写成// 错误示例 condition.awaitNanos(5000); // 继续执行——以为肯定在 5 毫秒内被唤醒或超时了问题在于awaitNanos在等待途中如果被虚假唤醒它会重新计算剩余时间并再次进入等待循环。如果业务代码直接忽略返回值你根本不知道当前是被正常唤醒还是已经超时了。标准做法是写一个循环不断扣除已经消耗的时间long remainingNanos 5000; lock.lock(); try { while (count 0 remainingNanos 0) { remainingNanos notEmpty.awaitNanos(remainingNanos); } if (remainingNanos 0) { // 超时处理 return null; } // 条件满足正常取出数据 } finally { lock.unlock(); }我还见过一种写法是在while循环外面用一个System.nanoTime()掐表超时时间是当前时间 - 开始时间效果一样但代码更啰嗦。建议直接用awaitNanos的返回值简洁且不容易出错。6.4 陷阱四await 使用前必须持有锁但 await 释放的锁和当前持有的是同一把锁这句话听起来是废话但实际编码中真的有人会踩坑。condition对象是通过lock.newCondition()创建的它和特定的lock实例绑定。如果某个方法里通过lockA.newCondition()创建了conditionA在另一个方法里却用conditionB.await()即使两个Condition是从同一个Lock上创建的也会在运行时抛出IllegalMonitorStateException——因为当前线程只持有与conditionB关联的那份锁另一份锁可能已经被其他线程持有了。更隐蔽的错误是锁的重入导致await无法完全释放。假设当前线程对lock重入了两次state为 2然后调用condition.await()AQS 会通过fullyRelease把state减到 0 并释放锁。但如果线程在await返回后acquireQueued重新获取锁时只将state恢复到 1 而不是 2那么外层锁的逻辑就会被破坏——再次unlock时state减到 0而实际只应该减到 1。好在 JDK 的fullyRelease和acquireQueued是成对设计的await返回后state会恢复成完整值这个细节不需要开发者操心。但知道这一点能帮你理解一个现象await之后的代码里锁的重入计数和你调用await之前是完全一样的。7. 条件队列的取消节点清理机制7.1 为什么会有取消节点await的等待过程并不是铁板一块。线程可能在等待期间被中断、或者awaitNanos超时这时节点就不能再留在条件队列里了否则后续signal会唤醒一个已经不想再等的线程白白浪费一次唤醒机会。取消节点在条件队列里的形态是状态值不再是CONDITION而是变成了CANCELLED或者 0表示正在转移。signal循环转移时遇到这类节点会直接跳过但这个跳过动作不会主动把它们从链表里摘除只是不处理而已。这就导致条件队列里会积累一些僵尸节点。7.2 unlinkCancelledWaiters 的清理时机await方法在重新获取锁之后有一段清理逻辑if (node.nextWaiter ! null) unlinkCancelledWaiters();unlinkCancelledWaiters会遍历当前条件队列把所有状态不是CONDITION的节点从链表中摘除。这个方法只在当前节点还有nextWaiter指针时才执行——如果当前节点是最后一个节点说明它后面没有别的节点了链表里没有需要清理的后续节点跳过清理也没问题。这个清理动作是惰性的不是每次await都会触发触发条件是当前节点后面还有节点。所以条件队列里的取消节点不会立即被清除而是在后续某个await调用时被顺带处理。这个设计我用大白话翻译一下JDK 不会主动帮你擦屁股但在你下次进卫生间的时候它会顺手把之前的垃圾也倒了。8. 阻塞队列的 Condition 内部实现参考JDK 自带的ArrayBlockingQueue其实就是一个生产级的Condition用法范例。它内部持有一个ReentrantLock对象lock以及两个Condition// java.util.concurrent.ArrayBlockingQueue 内部结构 final ReentrantLock lock; private final Condition notEmpty; private final Condition notFull; public ArrayBlockingQueue(int capacity, boolean fair) { lock new ReentrantLock(fair); notEmpty lock.newCondition(); notFull lock.newCondition(); }put方法的核心逻辑和我们上面写的BoundedBuffer几乎一模一样只是多了count递增、itrs迭代器维护等细节。take方法也类似用的是notEmpty.await()和notFull.signal()。我建议大家读一读ArrayBlockingQueue的源码特别留意它在put和take中signal的顺序——入队后先signal notEmpty出队后先signal notFull。这个顺序不是我随便定的而是有讲究的如果你先释放锁再signal那signal时可能触发IllegalMonitorStateException因为锁已经不在你手里了。所以在finally块中unlock()之前必须完成所有signal操作。9. 排查 Condition 问题的思路查清单最后把我这几年排查Condition相关问题积累的经验整理成一个清单遇到并发异常时按这个顺序逐项排查大多数问题都能定位到。1. 确认所有 await/signal 调用都在持有锁的代码块内 - 报 Ill egalMonitorStateException 先查这个 2. 确认 await 被 while 循环包裹循环条件是等待谓词 - 排查死锁或数据不一致时优先看是不是 if 写成了 while 3. 确认 signal 唤醒的是正确的条件队列 - 生产者唤醒 notEmpty消费者唤醒 notFull 4. 确认所有等待路径上都有对应的 signal 触发 - 检查代码里每个修改共享状态的地方是否都补了 signal 5. 确认超时等待的返回值和剩余时间处理正确 - awaitNanos 的返回值要用于循环条件 6. 确认没有在持锁情况下调用 signal然后立即 unlock 导致唤醒顺序问题 - signal 必须在 unlock 前完成但不要在 signal 后做耗时操作 7. 线程 dump 里看到 waiting on condition 时检查条件谓词是否长期不满足 - 可能业务逻辑本身有问题条件永远无法为 true第 3 条和第 4 条是实际项目中最容易出问题的点。尤其是代码重构后很容易出现某个调用点忘记signal的情况导致线程永久挂起。一个有效的防御手段是写单元测试专门验证无论执行顺序怎么排列put和take都能正常完成用多线程随机调度来暴露丢失唤醒的问题。10. 从原理到实践Condition 的适用场景与选型建议到这儿Condition的核心机制和实战技巧基本讲完了。最后从工程选型的角度给大家一个参考范围什么场景下用Condition什么场景下可以用更高级的并发工具替代。Condition最适合的场景是你需要在持有锁的状态下精细控制多个等待条件并且需要手动管理唤醒逻辑。典型的有界缓冲区、资源池、任务调度队列都属于这一类。此时用Condition的实现最灵活性能也可控。如果你只是想实现生产者放入数据后消费者自动被唤醒BlockingQueue系列ArrayBlockingQueue、LinkedBlockingQueue开箱即用完全不必要自己手写Condition。如果你需要的是多个线程都到达某一点后一起放行CountDownLatch或者CyclicBarrier更合适语义更清晰。如果只是简单的一对一通知CompletableFuture或者BlockingQueue的offer/poll也够用。但无论选哪个工具Condition背后的条件谓词 循环检查 精准唤醒这套思维模式都是通用的。这些思想理解透了再去读LinkedBlockingQueue、DelayQueue、SynchronousQueue的源码会发现万变不离其宗。我个人在实际项目里的体会是并发编程最容易出的问题不是 API 用错而是对条件与唤醒的因果关系没想清楚。每次写await之前先问自己三个问题这个条件什么时候会被满足由谁来触发满足的动作所有可能满足条件的路径上是否都覆盖了signal把这三个问题想透了Condition这块的坑基本上就能避开一大半了。