condition_variable::wait必须用while循环而非if，因为存在虚假唤醒——线程可能无通知被唤醒，需每次醒来都重新验证条件；谓词重载仅封装while逻辑，不解决原子性与可见性问题。
为什么condition_variable::wait必须配while而不是if
虚假唤醒（spurious wakeup）是condition_variable的合法行为——线程可能在没有收到notify_one/notify_all的情况下被唤醒。这不是bug，是POSIX和C++标准允许的实现优化（比如信号中断、内核调度抖动）。一旦用if检查条件，线程醒来后直接往下走，大概率读到错误状态，引发数据竞争或逻辑崩溃。
真实场景中，你无法区分一次唤醒到底是“真通知”还是“假唤醒”，唯一可靠的做法是：每次醒来都重新验证业务条件是否真正满足。
实操建议：
- 永远用
while (condition_is_false) cv.wait(lock)，不要用if - 条件判断必须是**可重入、无副作用**的纯检查（比如
queue.empty()可以，queue.pop()不行） - 把条件检查写成独立函数或lambda，避免重复逻辑和漏检
wait的谓词重载为什么能帮你少写几行但不能省心
condition_variable::wait提供了带谓词的重载：cv.wait(lock, []{ return !queue.empty(); });。它内部就是帮你包了一层while循环，语义等价于手写while(!pred()) wait(lock)。
但它不解决根本问题：谓词本身仍需严格满足原子性与可见性。常见翻车点：
- 谓词里访问的变量没被同一
mutex保护（比如queue用了mutex，但shutdown_flag是单独的atomic，却没在谓词里一并检查） - 谓词返回
true后，临界区还没进入，其他线程已改写状态（典型竞态），所以仍要靠锁+检查+操作三步原子组合 - 调试时容易误以为“用了谓词就安全了”，结果把条件拆散在多个地方检查
生产者-消费者模型里最容易漏掉的两个检查点
以带退出信号的队列为例，仅检查!queue.empty()远远不够。真实线程退出逻辑往往需要同时满足多个条件，缺一不可：
- 队列非空 且 未收到关闭信号：
while (queue.empty() && !shutdown_requested) - 如果支持“清空后退出”，还要考虑：唤醒时队列为空，但
shutdown_requested == true，此时应跳出循环而非继续等待 - 注意
shutdown_requested如果是std::atomic，读取它不需要锁，但必须和queue的状态一起纳入谓词——否则可能刚读完queue.empty()==true，另一线程就设了shutdown_requested=true，而本线程还在等
示例片段：
std::unique_lock<:mutex> lock(mtx);
cv.wait(lock, [&]{ return !queue.empty() || shutdown_requested; });
if (shutdown_requested && queue.empty()) {
break; // 退出消费循环
}
auto item = std::move(queue.front());
queue.pop();
</:mutex>
用notify_all还是notify_one？和虚假唤醒有关吗
无关。notify_one只唤醒一个等待线程，notify_all唤醒所有——但无论哪种，每个被唤醒的线程都必须重新检查条件。虚假唤醒不是由通知方式引起的，而是底层futex或pthread_cond_wait的固有特性。
选择依据是业务语义：
- 单个资源可用（如一个任务、一个连接）→ 用
notify_one，避免惊群 - 状态变更影响多个等待者（如广播“停止服务”）→ 必须用
notify_all，否则部分线程永远卡住 - 即使用了
notify_one，也要假设其他等待线程可能被虚假唤醒，所以每个线程的while检查不能省
真正容易被忽略的是：notify_*调用本身不在临界区内也可能出问题——比如修改完queue后先解锁再notify，中间可能有其他线程插入并再次修改状态。稳妥做法是：在持有锁期间完成状态更新+通知。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
