notify_one() 有时不唤醒预期消费者，因其仅随机唤醒一个等待线程且不检查谓词；正确做法是始终用 while 循环配合谓词重检，并在持锁状态下更新状态后通知。
为什么 notify_one() 有时不唤醒预期的消费者？
条件变量本身不保存状态，notify_one() 只是随机唤醒一个在 wait() 中阻塞的线程——它不关心谁“该被唤醒”，也不检查谓词是否满足。如果多个消费者等待、但生产者只发一次通知，而被唤醒的是刚处理完还没来得及重新等待的消费者（即虚假唤醒后未重检条件），就可能跳过真正需要数据的线程。根本原因在于：唤醒和条件检查必须原子绑定在同一个锁+谓词结构中，不能靠“通知次数匹配”来保证精准。
实操建议：
- 永远用
while (condition) cv.wait(lock)，不用if—— 防止虚假唤醒导致跳过检查 - 生产者在修改共享状态（如往队列 push）后，再调用
cv.notify_one()或cv.notify_all()，且必须在持有同一把互斥锁的前提下完成状态更新和通知（或至少确保修改对唤醒线程可见） - 若需“唤醒特定类型消费者”，条件变量做不到——应改用多个条件变量（如
cv_has_data和cv_has_space）或结合标志位 +notify_all()让所有线程竞争检查谓词
单个条件变量能否实现“一对一”唤醒？
不能。C++ 标准库的 std::condition_variable 没有绑定线程身份或优先级的能力。notify_one() 的行为是未指定的（implementation-defined），实际中常按等待顺序唤醒，但不保证 FIFO，更不保证唤醒“最久没被服务的消费者”。所谓“精准”，只能靠谓词设计来达成逻辑上的精确性，而非调度层面的精确。
典型场景下正确做法：
- 使用一个共享队列 + 一把互斥锁 + 一个条件变量
cv_not_empty - 消费者等待：
while (queue.empty()) cv_not_empty.wait(lock) - 生产者入队后：
queue.push(item); cv_not_empty.notify_one(); - 注意：即使只有一个消费者，也要用
while——因为notify_one()可能在消费者尚未进入wait()时发出（即丢失通知），此时需靠循环+谓词重检兜底
何时必须用 notify_all() 而非 notify_one()？
当谓词不是互斥独占型时，比如多个消费者可处理不同类别的任务，或存在“广播式”状态变更（如关闭信号、重置缓冲区），单次 notify_one() 可能唤醒一个发现条件仍不满足的线程，导致其余线程继续沉睡，系统停滞。
常见触发条件：
- 共享状态变化影响多个等待线程的判断（例如：队列清空后通知“所有等待取数据的线程，现在没数据了”）
- 使用了多个不同谓词共用一个条件变量（不推荐，但偶有遗留代码）
- 消费者带有超时等待（
wait_for），部分线程已超时退出，剩余线程的等待条件可能因新事件失效，需全部重检 -
notify_all()开销略高，但现代实现（如 glibc）在无等待线程时基本无成本；真正瓶颈通常是锁竞争，而非通知本身
容易被忽略的内存序与初始化陷阱
条件变量本身不提供内存同步保证，它依赖关联的 std::mutex 来建立 happens-before 关系。如果漏掉锁保护，或在锁外修改共享数据，会导致消费者看到撕裂的队列状态（如 size == 1 但实际为空）。
关键细节：
-
cv.wait(lock, pred)等价于while(!pred()) { cv.wait(lock); }，且在每次进入wait()前自动释放锁，在唤醒后自动重新获取锁并再次检查谓词——这个“释放-等待-重获”过程是原子的 - 不要手动调用
lock.unlock()后再wait()，否则破坏原子性，引发未定义行为 - 条件变量和互斥量都必须在所有线程开始使用前完成构造（静态/全局对象安全；局部对象若被引用则需确保生命周期）
- Linux 下若程序 fork()，子进程继承的条件变量和互斥量处于未定义状态，不可复用
精准唤醒的本质不是调度魔法，而是让每个线程在每次被唤醒后，都严格依据当前最新共享状态做决策。这要求每行读写都被锁覆盖，每个 wait() 都配对 while 循环，每次 notify 都发生在状态已提交之后——少一个环节，就可能漏掉本该发生的唤醒。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
