必须用while循环包裹std::condition_variable::wait()，因其可能虚假唤醒；正确做法是while(cond) wait()或使用带谓词的wait(lock,[]{return cond;})，且notify须在修改状态后、解锁前执行。
这通常不是“条件互斥”出了问题，而是你把 std::condition_variable::wait() 和条件检查混在一起了——它根本就不是“互斥”的判断逻辑，而是一个**可能被虚假唤醒（spurious wakeup）打断的等待机制**。
为什么 wait() 必须用 while 而不能用 if
因为 wait() 返回时，条件未必真的成立。操作系统或硬件可能在没收到 notify_one() 或 notify_all() 的情况下就让线程醒了（这就是虚假唤醒），或者多个线程被同时唤醒但只有第一个能真正处理任务，其余线程再检查时条件已不满足。
常见错误写法：
std::unique_lock<:mutex> lock(mtx);
if (data_ready == false) { // ❌ 危险！只检查一次
cond.wait(lock);
}
// 后续代码假设 data_ready 一定为 true
</:mutex>
正确做法永远是：
- 用
while循环包裹wait()，每次唤醒都重新检查条件 - 把条件变量和互斥锁绑定在同一临界区中，确保检查和等待原子性
- 修改条件的线程必须在持有同一把锁的前提下，先改状态再调用
notify_*
wait() 的参数决定了是否自动重检
wait() 有两个重载版本：
-
cond.wait(lock)：只阻塞，不检查，醒来后必须手动判断 -
cond.wait(lock, []{ return condition; })：传入一个可调用对象，wait内部会自动用while包裹它——这才是推荐写法，省去手写循环的疏漏
例如：
std::unique_lock<:mutex> lock(mtx);
cond.wait(lock, []{ return !queue.empty(); }); // ✅ 安全、简洁、标准做法
// 醒来时 queue 一定非空
</:mutex>
这个 lambda 不是“执行两次”，而是每次唤醒都执行一次检查；如果失败，wait 会自动再次挂起线程。
notify 时机不对也会导致“重复执行”假象
如果你在释放锁之后才调用 notify_one()，就可能出现“唤醒丢失”：等待线程还没进入 wait，通知已经发出去了，结果它一直等下去；而另一个线程后来也进来了，两个线程最终都执行了后续逻辑——看起来像条件被触发了两次。
务必保证 notify 发生在同一个临界区内，且在修改共享状态之后、解锁之前：
- ❌ 错误：先
unlock()，再notify_one() - ✅ 正确：改完
data_ready = true→ 立即cond.notify_one()→ 再unlock()
最常被忽略的一点：条件变量本身不保存状态，它只是个“叫醒器”。所有状态判断必须由你自己用普通变量（如 bool、int、queue.size()）维护，并始终配合互斥锁保护。一旦漏掉某次检查、或 notify 位置松动，行为就不可预测了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
