结论：必须用while循环或cv.wait(lock, pred)防御虚假唤醒，否则必然导致未定义行为；通知端须在锁内原子完成状态更新与notify，否则唤醒线程将看到不一致状态。
直接说结论：所有没用 while 循环或没用带谓词的 cv.wait(lock, pred) 的等待逻辑，只要涉及共享状态变更，就大概率在压力下出错——不是“可能”，是“几乎必现”。虚假唤醒不是小概率事件，是标准允许的合法行为，不防御等于裸奔。
为什么 if (cond) cv.wait() 一定会崩溃或读脏数据
虚假唤醒不是 bug，是 POSIX 和 C++ 标准明确放行的行为。内核调度、信号中断、futex 实现细节都可能让它发生。一旦你写成：
std::unique_lock<std::mutex> lk(mtx); if (!ready) cv.wait(lk); // ❌ 错误示范 // 后续直接使用 ready 对应的数据
线程醒来后 ready 仍是 false，但代码已跳过检查，继续读取未初始化内存、解引用空指针、或从空队列 pop() —— 这些都不是“偶发崩溃”，而是确定性未定义行为。
- 哪怕只在测试中跑通，上线后在高并发、CPU 抢占激烈或容器化环境中，几秒内就会复现
- gdb 调试时很难捕获，因为唤醒和后续操作之间没有断点；加日志反而可能掩盖竞态
- 这种错误不会报 “spurious wakeup” 错误信息，只会表现为 segfault、assert 失败、数据错乱等下游症状
cv.wait(lock, pred) 和手写 while 循环怎么选
优先用 cv.wait(lock, []{ return !queue.empty(); })，它内部就是展开为 while (!pred()) cv.wait(lock);，语义清晰、不易漏写循环、且编译器能做一定优化。
立即学习“C++免费学习笔记（深入）”；
- 谓词必须无副作用：不能调用
queue.pop()、不能修改计数器、不能抛异常 - 如果谓词开销大（比如要遍历 vector 查找某个元素），手动写
while更可控，可提前缓存查找结果 - 绝对不要混用：比如外层
if (flag) cv.wait(lock, pred);，再在返回后又检查一遍 flag —— 状态可能已被其他线程改过，逻辑自相矛盾
生产者-消费者里最容易漏掉的复合条件检查
只检查 !queue.empty() 不够。真实场景往往要同时满足多个条件，比如队列非空 且 没收到关闭信号：
cv.wait(lk, [&]{ return !queue.empty() && !shutdown_flag.load(std::memory_order_acquire); });
-
shutdown_flag是std::atomic<bool>？那它的load()必须用acquire语义，否则编译器或 CPU 可能重排指令，导致看到 queue 非空但 shutdown_flag 还是旧值 - 更稳妥的做法是把
shutdown_flag也放进同一互斥锁保护，避免跨锁状态不一致 - 唤醒后、真正
front()和pop()前，必须仍在同一个std::unique_lock下完成——否则其他消费者可能已在你检查完、取数据前清空了队列
notify_one() 放错位置比 wait 写错更难排查
最常被忽略的是通知端逻辑：状态更新和 notify_one() 必须在同一个锁作用域内完成。
- 错误模式：先
mtx.unlock()，再cv.notify_one()→ 其他线程可能刚进入wait()就错过通知 - 更隐蔽的错误：
queue.push(item)和cv.notify_one()不在同一个锁里 → 等待线程醒来时看到的可能是部分更新的状态 - 正确写法：锁住、改状态、通知、解锁 —— 三步原子落在一个临界区里
复杂点在于：虚假唤醒本身不可控，但“唤醒后看到旧状态”是可以预防的。关键不在等的那一边，而在通知那一边是否严格配对。稍有松动，整个同步逻辑就退化成竞态游戏。
