wait()必须配合while循环使用，因为虚假唤醒是标准允许的合法行为，仅用if会导致线程误判条件成立而读取未更新数据或触发未定义行为。
虚假唤醒不是 bug，是条件变量的合法行为；不加谓词循环检查的 wait() 必然出错。
为什么 wait() 必须配合 while 循环使用
条件变量的 wait() 可能在没有被 notify_one() 或 notify_all() 唤醒的情况下返回（即虚假唤醒），这是 POSIX 和 C++ 标准明确允许的行为。操作系统内核、调度器优化、信号中断都可能触发它。如果只用 if 判断一次，线程就会误以为条件已满足，直接向下执行，大概率读到未更新的数据或进入非法状态。
实操建议：
- 永远用
while (condition_is_false) cv.wait(lock);，别用if - 谓词必须是可重复求值、无副作用的表达式（比如
queue.empty()，而不是pop_if_not_empty()） - 检查和等待必须在同一个互斥锁保护下完成，否则存在竞态窗口
std::condition_variable::wait() 的两种重载怎么选
C++ 提供了带谓词的重载：wait(unique_lock<mutex>& lock, Predicate pred)</mutex>，它等价于手动写的 while 循环 + wait()。但很多人没意识到它的底层逻辑和陷阱。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 推荐优先使用带谓词的重载，代码更简洁且不易漏写循环 —— 它内部就是帮你展开成
while (!pred()) wait(lock); - 注意：谓词对象会被多次调用，不能依赖其调用次数，也不能在里面修改共享状态（比如计数器自增）
- 如果谓词计算开销大（如遍历容器找元素），手动写 while 更可控，可提前缓存部分结果
- 不要混用：避免在外层 if 里调用谓词版
wait()，再在唤醒后又检查一遍——这属于冗余且可能因状态变化导致逻辑错乱
典型错误场景：生产者-消费者中漏判空队列
一个常见翻车点是消费者线程在 wait() 返回后直接 pop()，却没再次确认队列非空。尤其当多个消费者共用一个条件变量、且用 notify_all() 时，虚假唤醒 + 竞争会导致 pop() 在空队列上触发未定义行为。
示例对比：
// ❌ 错误：if + 单次检查 std::unique_lock<std::mutex> lk(mtx); cv.wait(lk); // 唤醒后不检查，直接 pop item = queue.front(); // queue 可能仍为空 queue.pop();
// ✅ 正确：谓词版 wait 自动处理
std::unique_lock<std::mutex> lk(mtx);
cv.wait(lk, [&]{ return !queue.empty(); });
item = queue.front();
queue.pop();
关键点：
- 谓词
[&]{ return !queue.empty(); }在每次唤醒后重新求值 - 即使被虚假唤醒，也会再次进入等待，直到条件真正成立
- 整个过程原子地持锁，避免检查和 pop 之间被其他线程修改队列
进阶提醒：notify 时机与 spurious wakeup 的边界情况
虚假唤醒虽小概率，但在高负载、多核、频繁 notify 场景下出现频率会上升。更隐蔽的问题是：notify 发生在 wait 进入等待前（即“lost wakeup”），这时仅靠谓词循环还不够，需确保 notify 永远在状态变更之后、且在锁保护下发出。
实操建议：
- 生产者 notify 前必须先修改共享状态（如 push 入队），且该修改与 notify 都在同一个
unique_lock保护下 - 不要在锁外修改状态再锁内 notify —— 中间可能被调度切走，导致消费者醒来发现状态仍未变
- 若使用
notify_all()，所有等待线程都会被唤醒并重新检查谓词，性能开销比notify_one()大，但逻辑更鲁棒；除非确定只有一个消费者能处理，否则别盲目优化成notify_one()
最易被忽略的一点：谓词里的状态检查必须和 notify 前的状态更新操作，读写的是同一组内存位置，并通过同一把互斥锁同步 —— 否则即使写了 while，也可能因内存可见性问题永远等下去或误判。
