Condition.await()无法唤醒指定线程，因其不保存线程身份且signal()仅唤醒等待队列首节点；定点唤醒需按等待意图创建独立Condition实例，并配合while循环+锁保护的条件检查。
Condition.await 为什么不能直接唤醒指定线程
Condition.await() 本身不保存调用线程的身份信息，挂起后线程进入等待队列（FIFO），而 signal() 只是唤醒队列头部的一个线程，signalAll() 唤醒全部——它没有“按名字”“按条件”或“按 ID”唤醒的能力。所谓“精准定点唤醒”，本质是靠**业务逻辑控制等待/唤醒的时机和对象**，而非 Condition 自身提供该能力。
常见错误现象：多个线程共用同一个 Condition，只靠 signal() 就想唤醒某一个特定线程，结果唤醒了别的线程，导致逻辑错乱或死锁。
- 必须为不同唤醒目标准备独立的
Condition实例（即多个ReentrantLock.newCondition()） - 每个线程应明确知道自己该 await 哪个
Condition，且只有对应逻辑能signal()它 - 避免在单个
Condition上混合多种等待语义（比如“等数据就绪”和“等资源释放”混在一起）
如何为不同线程分配专属 Condition 实例
关键不是“给线程编号”，而是**按等待意图建模**。例如：线程 A 等待“缓冲区非空”，线程 B 等待“缓冲区未满”，它们天然应使用两个不同的 Condition：
private final ReentrantLock lock = new ReentrantLock(); private final Condition notEmpty = lock.newCondition(); // 供消费者 await private final Condition notFull = lock.newCondition(); // 供生产者 await
使用场景：生产者-消费者、多阶段任务协调、状态机驱动的线程协作。
- 一个
ReentrantLock可以关联任意多个Condition，互不干扰 - 每个
Condition维护自己的等待队列，signal()只影响其队列中的线程 - 不要复用
Condition实例跨不同语义场景，否则会破坏“定点”前提
await 必须配合 while 循环检查条件变量
即使你用了专属 Condition，await() 返回后也不能直接认为条件已满足——可能被虚假唤醒（spurious wakeup），也可能唤醒后条件又被其他线程改回不满足状态。
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
典型错误写法：if (buffer.isEmpty()) notEmpty.await(); → 一旦唤醒就往下走，极大概率出错。
- 正确模式是：
while (!conditionHolds()) notEmpty.await(); - conditionHolds() 必须是受同一把锁保护的共享状态判断（如
buffer.size() > 0） - 每次
signal()后，务必在持有锁的前提下修改对应条件变量，并显式调用signal()（而不是依赖信号丢失自动重试）
signal 调用时机与锁持有关系
signal() 必须在持有对应 ReentrantLock 的前提下调用，否则抛 IllegalMonitorStateException。但更重要的是：**signal 之后是否立即释放锁，会影响被唤醒线程能否立刻抢到锁继续执行**。
性能与行为差异：
- 推荐写法：在修改完条件变量后，仍在锁内 调用
signal()，然后才unlock()。这样被唤醒线程有机会在唤醒后直接获取锁，减少上下文切换 - 危险写法：先
unlock()再signal()→ 此时唤醒的线程会立刻尝试抢锁失败，陷入二次阻塞，白白增加延迟 -
signal()不保证唤醒线程马上运行，只是将其从等待队列移到同步队列；最终调度仍由 JVM 和 OS 决定
真正容易被忽略的点：Condition 的“精准”完全依赖你对等待意图的拆分粒度和条件变量更新的原子性。没有独立 Condition，就没有定点；没有 while + 锁保护的条件检查，就没有可靠性。
