条件变量本身不保存状态，仅配合互斥锁实现线程等待与唤醒；“精准通知”依赖程序员用while循环反复检查谓词，避免虚假唤醒和丢失唤醒，且signal必须在共享状态更新后、同一mutex保护下执行。
条件变量（Condition Variable）本身不保存状态，它只是配合互斥锁（Mutex）使用的同步原语，用于让线程在某个“条件不满足”时挂起，等其他线程修改共享状态并显式通知后才被唤醒。await/signal 的“精准通知”，关键不在条件变量本身，而在于程序员如何用它正确封装“等待-检查-唤醒”的逻辑闭环。
await 不是直接等待变量，而是等待谓词为真
所谓“精准”，是指线程只在真正关心的业务条件成立时才继续执行，而非仅仅收到信号就贸然往下走。这要求 await 必须包裹在一个 while 循环中，反复检查谓词（predicate），例如：
while (!queue.empty()) { cond.await(mutex); }
原因有二：一是存在虚假唤醒（spurious wakeup），系统可能无理由唤醒线程；二是 signal 可能发生在 await 之前（即“丢失唤醒”），若不重检条件，线程会错误地认为条件已满足。因此，await 的语义本质是“释放锁 → 挂起 → 被唤醒 → 重新加锁 → 再次检查条件”。
signal 并不保证唤醒特定线程，但可控制唤醒时机
signal 做的事很轻量：它只是标记“可能有线程该醒了”，然后由调度器选择一个在该条件变量上等待的线程唤醒。它不传递参数、不指定目标、也不保证立即执行。要实现“精准”，必须确保 signal 发生在共享变量已更新且新状态确实满足等待者谓词之后，例如：
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
- 先修改共享数据（如 push 一个元素到队列）
- 再调用 signal（此时其它线程醒来检查 queue.empty() 就会为 false）
- 整个过程需在同一个 mutex 保护下完成，避免中间态被并发读取
await/signal 配合 mutex 构成原子性的“等待-响应”边界
mutex 在这里不只是保护数据，更是定义了“临界区”的范围，让等待和通知形成逻辑上的配对。典型模式如下：
// 等待方
mutex.lock();
while (!condition_met()) {
cond.await(mutex); // 自动释放锁并挂起，唤醒时自动重持锁
}
// 此时 condition_met() 为 true，安全操作共享数据
mutex.unlock();
// 通知方
mutex.lock();
update_shared_state(); // 如设置 flag = true 或插入数据
cond.signal(); // 此时等待线程醒来后能立刻看到新状态
mutex.unlock();
这个结构保证了：从等待线程视角，它看到的状态变更和 signal 是不可分割的；从通知方视角，signal 总是伴随着一次真实有效的状态更新。
signal vs broadcast：选对唤醒粒度才能“精准”
signal 唤醒至多一个等待线程，broadcast 唤醒所有。所谓“精准”，往往意味着只唤醒真正需要的那个线程。比如生产者-消费者中，一个新元素只需唤醒一个消费者，用 signal 即可；但如果多个线程在等“任意资源就绪”，而资源可用性是全局变化的（如配置重载完成），则 broadcast 更合适。误用 broadcast 会造成“惊群效应”，大量线程争抢锁、重复检查条件，降低效率；而过度依赖 signal 可能在多消费者场景下导致部分线程永久阻塞（如 signal 刚好唤醒了一个不匹配任务类型的线程）。所以，“精准”也体现在根据业务语义选择唤醒方式。
