Condition 是 Java 并发包中用于替代 wait/notify 的核心接口，必须与 Lock 配合使用，基于 AQS 实现独立条件队列，支持多条件精准唤醒与原子 await/signal 操作。
Condition 是 Java 并发包中 java.util.concurrent.locks 下的核心接口，用于替代传统的 Object.wait()/notify()，提供更灵活、精确的线程等待与唤醒控制。它必须与 Lock（通常是 ReentrantLock）配合使用，每个 Lock 可关联多个 Condition 实例，从而实现“按条件细分等待队列”的能力。
Condition 依赖 AQS 的条件队列机制
Condition 的底层实现完全基于 AbstractQueuedSynchronizer（AQS） 的内部结构。每个 ConditionObject（ReentrantLock 中 Condition 的默认实现）维护一个独立的**单向条件等待队列**，节点类型为 Node.CONDITION。该队列与 AQS 的同步队列（用于锁竞争）物理分离，互不干扰。
- 调用
await()时，当前线程会从同步队列中移除，封装为Node加入条件队列尾部，并释放锁（触发 full release），然后阻塞； - 调用
signal()时，仅将条件队列队首的 Node 从条件队列中摘下，转移到 AQS 同步队列的尾部，使其具备参与锁竞争的资格； - 条件队列中的节点不会参与锁的获取竞争，只有被转移后才进入同步队列排队。
多个 Condition 实现“分组等待”
同一把 ReentrantLock 可创建多个 Condition 实例，例如：
Lock lock = new ReentrantLock(); Condition notFull = lock.newCondition(); // 等待“非满”条件 Condition notEmpty = lock.newCondition(); // 等待“非空”条件
这种设计天然支持不同业务逻辑的等待隔离：
立即学习“Java免费学习笔记（深入）”；
- 生产者只在
notFull上await()，消费者只在notEmpty上await()； -
signal()可精准唤醒对应角色（如生产者唤醒消费者），避免notifyAll()带来的无差别唤醒和虚假唤醒风险； - 各条件队列独立管理，互不影响，提升响应精度与吞吐效率。
await() 的原子性与状态恢复逻辑
await() 不是简单挂起，而是一组原子操作组合：
- 检查线程中断状态，若已中断则直接抛出
InterruptedException； - 将当前线程构造成
Node加入条件队列； - 完全释放锁（可能多次 release，以匹配重入次数）；
- 阻塞线程（
LockSupport.park(this)）； - 被唤醒后，重新获取锁（可能阻塞在同步队列中），并检查是否因中断被唤醒，决定是否补上中断标志或抛异常；
- 若成功获得锁且未中断，则从条件队列中移除该节点，返回继续执行。
signal() 与 signalAll() 的差异本质
二者区别在于转移节点的范围：
-
signal()：仅将条件队列头节点移至同步队列尾部； -
signalAll()：遍历整个条件队列，将所有节点依次移入同步队列（顺序保持 FIFO）； - 注意：
signal()不保证唤醒的是“等待最久”的线程，而是队列头部节点——但条件队列本身是 FIFO，所以实际效果等价； - 被转移的节点需再次竞争锁，因此
signal()并不等于“立即执行”，只是赋予其竞争资格。
Condition 的设计让等待/通知机制摆脱了 Object 监视器的全局单一队列限制，通过显式队列分离与精确唤醒，成为高并发场景下构建高效协作模型的关键基础设施。理解其与 AQS 的耦合方式，是掌握 ReentrantLock、ArrayBlockingQueue、LinkedBlockingQueue 等类底层行为的基础。
