虚假唤醒是线程未被显式唤醒却从wait()返回的现象，属标准允许行为；必须用while循环检查条件，因虚假唤醒后需重新验证，c++11谓词重载wait(lock,pred)等价于此循环。
什么是虚假唤醒，为什么wait()必须配合循环检查
虚假唤醒是指线程在没有被显式唤醒（如notify_one()或notify_all()）的情况下，从condition_variable::wait()中返回。这不是 bug，而是 POSIX 和 C++ 标准允许的行为——底层系统调用（如 futex_wait 或 pthreads_cond_wait）可能因信号、中断或内核调度等原因提前返回。
所以，**绝不能只写一次判断就调用 wait()**。正确做法是把条件检查放在 while 循环里：
std::unique_lock<:mutex> lock(mtx);
while (!data_ready) { // 必须用 while，不是 if
cv.wait(lock);
}
// 此时 data_ready 一定为 true（且已重新持锁）
</:mutex>
原因：即使发生虚假唤醒，循环会立刻重新检查条件；若条件仍不满足，继续等待。这是唯一符合标准的防御方式。
用 wait() 的重载版本自动处理循环？
C++11 提供了带谓词的 wait() 重载：cv.wait(lock, predicate)，它等价于手动写的 while(!predicate()) wait()。它更安全、更简洁，且避免手误写成 if。
但要注意两点：
-
predicate必须可调用、无副作用、不抛异常（通常用 lambda 或函数对象） - 它只适用于“条件可直接求值”的场景，比如
queue.empty()、flag.load()；如果条件依赖多个变量或需复杂计算，仍建议显式写while+ 手动检查
示例：
cv.wait(lock, []{ return !queue.empty(); }); // 安全、推荐
// 等价于：
// while (queue.empty()) {
// cv.wait(lock);
// }
为什么用 notify_all() 有时反而引发更多虚假唤醒风险？
notify_all() 本身不导致虚假唤醒，但它会唤醒所有等待线程——其中大部分可能发现条件仍未满足，于是立刻再次进入 wait()。这种“唤醒-检查-再等待”过程，在高竞争下看起来像频繁的虚假唤醒，实则是正常逻辑。
真正的问题在于：如果本该用 notify_one() 却误用 notify_all()，会导致不必要的线程调度开销，甚至加剧锁争用。反过来，如果多个等待者各自关心不同条件（比如生产者/消费者共用一个 cv），却只用 notify_one()，某些线程可能永远等不到对应通知。
建议：
- 单个条件、一对一唤醒（如“有新数据”）→ 优先用
notify_one() - 条件变化影响多个等待者（如“缓冲区已清空”，多个消费者都该重试）→ 用
notify_all() - 避免在持有锁期间做耗时操作后再
notify，否则唤醒的线程会立即阻塞在锁上
容易被忽略的细节：锁的生命周期和 wait() 的原子性
wait() 的关键契约是：它会原子地释放锁并挂起线程；被唤醒时，会原子地重新获取锁（此时线程才从 wait() 返回）。这意味着：
- 传给
wait()的lock必须是已持有的std::unique_lock，且不能是临时对象（如std::unique_lock<:mutex>(mtx)</:mutex>） - 不能在
wait()前手动unlock()，也不能在wait()后手动lock()—— 这破坏原子性，可能漏掉通知 - lambda 谓词里访问的共享变量，必须确保在锁保护下读取（
wait()返回时锁已重新持有，所以没问题）
常见错误写法：
// ❌ 错误：临时 unique_lock，析构时 unlock，wait 未执行就丢锁
cv.wait(std::unique_lock<:mutex>(mtx), []{ return done; });
// ✅ 正确：lock 是具名对象，生命周期覆盖整个 wait
std::unique_lock<:mutex> lock(mtx);
cv.wait(lock, []{ return done; });
</:mutex></:mutex>
虚假唤醒本身无法彻底消除，但只要坚持“循环检查 + 原子 wait + 正确 notify”，就能保证逻辑正确。最容易出问题的，其实是忘了 while，或者在谓词里读了没加锁的变量。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
