condition实现生产者-消费者模型需用notfull和notempty两个条件变量绑定同一reentrantlock，配合while循环防虚假唤醒，生产后signal notempty、消费后signal notfull，await前必须持锁且由condition自动管理锁释放与重入。

用 Condition 实现生产者-消费者模型的精准通知，核心在于让不同条件下的线程只响应自己关心的信号，避免无差别唤醒（比如 notifyAll() 带来的无效竞争），从而提升效率和可控性。

用 Condition 区分“有货可取”和“有空可放”两个条件

一个阻塞队列通常需要两个独立等待条件：

• notFull：消费者不关心，只有生产者在缓冲区满时 await，生产成功后 signal 生产者可能继续放；
• notEmpty：生产者不关心，只有消费者在缓冲区空时 await，消费成功后 signal 消费者可能继续取。

这两个 Condition 必须绑定在同一个 ReentrantLock 上，但各自维护独立的等待队列，互不干扰。

必须配合 while 循环做条件检查，防止虚假唤醒

即使被 signal，也不能直接执行操作，因为可能只是被意外唤醒（spurious wakeup）或条件已再次变化。正确写法是：

• 生产者入队前：while (queue.size() == capacity) notFull.await();
• 消费者出队前：while (queue.isEmpty()) notEmpty.await();

用 while 而非 if，确保每次唤醒后都重新验证业务条件是否真正满足。

signal 要用对人：谁该醒，就通知谁的 Condition

每次状态变更后，只唤醒真正可能推进流程的一方：

• 生产一个元素后：notEmpty.signal();（告诉等待取货的消费者可以干活了）；
• 消费一个元素后：notFull.signal();（告诉等待放货的生产者可以继续放了）。

切忌在生产后调用 notFull.signal()，那会唤醒其他生产者做无用等待；同理，消费后唤醒 notEmpty 也没意义。

锁的粒度要准：await 前必须持有锁，await 会自动释放，唤醒后自动重入

典型流程如下：

• 获取 lock → 检查条件 → 不满足则调用 condition.await()（自动释放锁）→ 被 signal 后重新竞争锁 → 拿到锁后从 await 返回 → 再次检查条件 → 满足则执行业务逻辑；
• 整个过程由 Condition 与 Lock 协作完成，无需手动 unlock/lock，否则会抛 IllegalMonitorStateException。

错误做法：先 unlock 再 await，或 await 后忘记在业务逻辑前后加 lock/unlock —— Condition 的语义完全依赖 lock 的上下文。