Condition 的 await() 和 signal() 不支持按名称、ID 或参数精准唤醒特定线程，只能唤醒同一 Condition 实例上等待的任意一个线程；需通过多个 Condition 实例分组、显式状态变量+while 循环判断、signal 而非 signalAll、以及动态等待注册表等方式间接实现逻辑级精准唤醒。
Condition 的 await() 和 signal() 本身**不支持按名称、ID 或条件参数精准唤醒某个特定线程**。它们是基于等待队列的协作机制，signal() 只能唤醒**同一个 Condition 实例上等待的任意一个线程**（通常是队列头），无法指定目标。所谓“精准唤醒”，需通过设计模式+多个 Condition + 显式状态控制来间接实现。
用多个 Condition 实例区分等待场景
不同逻辑含义的等待应使用独立的 Condition 对象，避免混用。例如生产者/消费者模型中：
- 用
notFullCondition 管理“缓冲区未满”这一条件，供生产者 await； - 用
notEmptyCondition 管理“缓冲区非空”，供消费者 await。
这样，notFull.signal() 只会唤醒正在等“有空间”的生产者线程，不会误唤醒消费者——这是最基础的“精准”分组。
结合显式状态变量 + 循环检查 await 条件
Condition 的 await 必须配合 while 循环判断业务条件（即所谓的“虚假唤醒防护”）。这个循环本身是实现逻辑级精准唤醒的关键：
- 假设线程 A 等待“任务 id == 1001”，线程 B 等待“任务 id == 1002”；
- 可定义一个共享的
volatile Task currentTask，并为每个任务 ID 创建专属 Condition（如task1001Cond）； - 线程 A 执行：
while (currentTask == null || currentTask.id != 1001) task1001Cond.await();
线程 B 同理； - 当设置
currentTask = new Task(1001)后，只调用task1001Cond.signal()，就只会唤醒线程 A。
避免 signalAll，优先用 signal + 状态驱动
signalAll() 会唤醒所有等待线程，导致竞争和无效唤醒。而单次 signal() 配合正确的状态更新，可确保只有真正满足条件的线程被唤醒并继续执行：
- 每次状态变更后，只对与该状态匹配的 Condition 调用
signal()； - 确保每次 signal 前，至少有一个线程在该 Condition 上 await 且其 while 条件即将成立；
- 若不确定是否有等待者，可用
signal()安全尝试——无等待者时无副作用。
慎用“一对一绑定”，必要时引入等待注册表
若需动态绑定线程与条件（如 RPC 响应唤醒发起请求的线程），可维护一个映射：
- 定义
ConcurrentMap，key 是请求 ID；waiters - 请求线程创建自己的
ReentrantLock.newCondition()，存入 map 并 await； - 响应到达时，根据响应 ID 查出对应 Condition，调用其
signal()； - 注意：每个线程应持有自己专属的 Condition，不可复用，且 await 前需加锁，signal 时也需在同锁下操作 map 和 condition。
