虚假唤醒不是bug，而是POSIX和硬件层面的妥协；必须用while循环检查条件，不能用if；notify_one比notify_all更精准；wait_for/wait_until超时返回也需同样处理。
虚假唤醒不是 bug，是 POSIX 和硬件层面的妥协
std::condition_variable 的虚假唤醒（spurious wakeup）不是 C++ 标准写错了，也不是 libstdc++ 或 libc++ 实现有缺陷。它源于底层 pthread_cond_wait 的行为规范——POSIX 允许、甚至鼓励实现为“在未收到 notify 时也返回”，因为这能避免某些锁竞争路径下的性能惩罚或死锁风险。现代 CPU 的内存重排、futex 唤醒机制的宽松语义、以及内核调度器对等待队列的批量处理，都可能让线程提前“醒来”。你不该试图消灭它，而必须接受它作为并发原语的固有特性。
必须用 while 循环检查条件，不能用 if
这是最常踩的坑：用 if 判断条件后直接 wait，一旦发生虚假唤醒，线程就带着错误前提继续执行，大概率导致逻辑崩溃或数据不一致。
正确做法始终是：
std::unique_lock<std::mutex> lock(mtx);
while (!data_ready) { // 注意：是 while，不是 if
cv.wait(lock);
}
// 此时 data_ready 一定为 true
为什么必须 while？
立即学习“C++免费学习笔记（深入）”；
- 虚假唤醒会让
wait返回，但条件仍为假 - 多个线程被 notify 时（比如
notify_all），只有部分线程真正满足条件，其余必须重新 wait - 条件变量只保证“被唤醒时条件*可能*成立”，不保证“成立才唤醒”
notify_one 和 notify_all 的选择直接影响虚假唤醒频率
看似无关，实则关键：滥用 notify_all 会显著放大虚假唤醒带来的开销和竞态复杂度。
使用场景与建议：
- 只有一个消费者等一个事件（如初始化完成）→ 用
notify_one，唤醒更精准，减少无谓的 while 检查 - 生产者放入一个任务，多个工作线程争抢 → 用
notify_one即可，由第一个抢到锁的线程消费，其余自动 continue 等下一次 - 广播式状态变更（如“全部暂停”）→ 才用
notify_all，但每个被唤醒线程仍要 while 检查自身是否真该响应 -
notify_all不等于“更安全”，它只是“更暴力”，反而掩盖条件判断缺陷
wait_for / wait_until 的超时返回也属于广义虚假唤醒
cv.wait_for(lock, 100ms) 返回时，lock 已重新持有，但条件未必成立——它可能只是超时了。这种返回和虚假唤醒在代码处理上完全一致：你无法区分“是被 notify 醒的”还是“是被 timeout 醒的”，所以依然得靠 while 循环兜底。
常见错误写法：
if (cv.wait_for(lock, 100ms) == std::cv_status::timeout) {
// 错！这里假设 timeout 就代表条件不满足，但 wait_for 成功返回也不代表条件真满足
}
正确写法仍是：
while (!data_ready) {
if (cv.wait_for(lock, 100ms) == std::cv_status::timeout) {
break; // 主动退出等待，但不跳过条件检查
}
}
// 出来之后仍要检查 data_ready
所有 wait 变体都只负责“等信号”，从不担保“信号有意义”。这个边界意识，比记住语法重要得多。
