虚假唤醒必须用while循环配合谓词检查来安全处理，因wait()可能无通知返回；if会导致逻辑错误；谓词需在锁内求值且无副作用，notify须与状态更新同锁执行。
虚假唤醒无法被完全避免，只能通过循环等待 + 谓词检查来安全处理；不加 while 循环直接用 if 是绝大多数死锁或逻辑错乱的根源。
为什么 wait() 必须配合 while 而不是 if
条件变量的 wait() 可能在没有收到 notify_one() 或 notify_all() 的情况下返回（即虚假唤醒），这是 POSIX 和 C++ 标准明确允许的行为。操作系统、调度器甚至硬件中断都可能触发它。如果只用 if (condition == false) cv.wait(lock);，线程醒来后不重新验证业务逻辑是否真正满足，就直接往下执行，大概率会读到脏数据、访问空指针或破坏状态一致性。
实操建议：
- 永远用
while (!predicate()) cv.wait(lock);，其中predicate()是一个可调用对象（lambda、函数对象或普通函数），返回布尔值 - 谓词必须在持有互斥锁的前提下求值，否则存在竞态：检查和 wait 之间状态可能被其他线程修改
- 不要把谓词逻辑拆成“先判断再 wait”两步——这是典型错误模式
std::condition_variable::wait() 的两种重载怎么选
C++ 提供了两个 wait() 重载：wait(std::unique_lock<:mutex>&)</:mutex> 和 wait(std::unique_lock<:mutex>&, Predicate)</:mutex>。后者看似方便，但容易掩盖对谓词语义的理解偏差。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 优先使用带谓词参数的重载（
cv.wait(lock, []{ return ready; });），它内部自动展开为等价的while (!pred()) wait(lock);，更简洁且不易漏写循环 - 但注意：这个谓词会被多次调用，不能有副作用（比如修改共享变量、抛异常、记录日志）
- 若谓词较复杂（如需多字段联合判断、涉及外部状态机），建议显式写
while循环，便于调试和加断点 - 绝对不要混用：比如在带谓词的
wait()外再套一层if或while，会导致重复判断或跳过唤醒
常见谓词设计错误与修复示例
谓词不是“有没有通知”，而是“我需要的业务状态是否已就绪”。很多开发者误把 flag 变量本身当谓词，忽略了状态转换的原子性要求。
错误现象：bool data_ready = false; 被多个线程读写，但未用 std::atomic 保护，或谓词中仅检查该变量却忽略关联数据是否已写完。
实操建议：
- 谓词应封装完整状态检查，例如：
[&]{ return !queue.empty() && processing_enabled.load(std::memory_order_acquire); } - 若涉及结构化数据（如缓冲区、对象指针），确保所有相关字段都在同一锁保护下更新，并在谓词中一并检查
- 避免在谓词里调用可能阻塞或抛异常的函数（如
std::filesystem::exists()） - 测试时可手动插入 sleep 或用
std::this_thread::yield()模拟调度干扰，验证循环等待是否真能扛住虚假唤醒
notify 侧也要守规矩：别忘了锁和时机
即使等待侧写对了，notify 侧出问题照样导致线程永远等下去。最常见的是：在没锁的情况下修改状态后调用 notify，或者 notify 早于状态更新。
实操建议：
- 状态修改和
notify_one()/notify_all()必须在同一个std::unique_lock<:mutex></:mutex>持有期间完成 - 推荐顺序：获取锁 → 修改共享状态 → 调用 notify → 释放锁。不要把 notify 放在锁外
- 用
notify_all()更安全，尤其当多个等待者依赖不同子条件时；但注意性能开销，必要时可用notify_one()配合更精细的状态建模 - 不要依赖“刚好 notify 一次”——虚假唤醒会让等待线程反复回来，所以 notify 后状态必须是稳定可重入的
最容易被忽略的一点：谓词里的变量必须是线程间同步过的。哪怕你用了 while 和锁，如果检查的变量本身没用 std::atomic 或没在锁内读取，编译器或 CPU 仍可能用寄存器缓存旧值，导致谓词永远返回 false。
