std::condition_variable卡住的根本原因是未配对使用mutex与wait()：条件变量不保护共享状态，所有读写共享变量（如ready）必须用同一std::unique_lock保护，且notify须在锁内完成；谓词检查必须用while循环防虚假唤醒。
std::condition_variable 为什么总卡住不唤醒
根本原因是没配对使用 std::mutex 和 wait() —— 条件变量自己不保护共享状态，只负责“通知”，状态变化必须由互斥锁保护。
- 常见错误：在
wait()前没加锁，或锁的对象和修改条件的不是同一个std::mutex - 正确姿势：用
std::unique_lock<:mutex></:mutex>构造后传给wait()，且所有读写条件变量所依赖的共享变量（比如ready标志）都必须在这把锁下进行 - 别用
std::lock_guard：它不能转移所有权，而wait()需要临时释放锁并等待，之后再重新获取，只有std::unique_lock支持这个行为
notify_one() 和 notify_all() 到底该选哪个
看等待者是否“可互换”：如果多个线程在等同一类事件，且处理逻辑完全一致（比如消费者线程池取任务），用 notify_one() 更高效；如果每个等待者对应不同条件分支，或你不确定谁该被唤醒，notify_all() 更安全。
-
notify_one()不保证唤醒“最先等待的那个”，只是唤醒一个未被中断的线程，具体哪个由调度器决定 - 用
notify_all()时，所有被唤醒线程会竞争锁，但只有拿到锁的那个能继续执行——其余线程会再次检查谓词（predicate），失败就继续 wait，所以谓词必须是 while 循环里检查，不能用 if - 性能差异明显：100 个线程在 wait，
notify_all()会触发 99 次无意义的锁竞争；notify_one()只唤醒一个，其余继续沉睡
wait() 的谓词为什么必须用 while 而不是 if
因为存在虚假唤醒（spurious wakeup）：即使没人调用 notify_xxx()，wait() 也可能返回。C++ 标准允许这么做，操作系统层面无法完全避免。
- 错误写法：
if (ready) { /* do work */ }→ 一旦虚假唤醒，直接跳过条件检查，可能访问未就绪资源 - 正确写法：
while (!ready) cv.wait(lock);→ 每次唤醒都重新检查条件，确保逻辑安全 - 更推荐用带谓词的重载：
cv.wait(lock, [&]{ return ready; });，它内部就是 while 循环，语义清晰还不易漏
跨线程传递数据时 condition_variable 容易漏掉什么
最常漏的是“修改共享状态”和“notify”之间的原子性断裂：先改数据、再 notify，中间被调度打断，导致等待线程看到旧状态、错过通知。
立即学习“C++免费学习笔记（深入）”；
- 典型坑：在
std::mutex外修改data，再进锁调用notify_one()→ 等待线程可能已在你改 data 后、notify 前醒来，检查到旧值又回去 wait - 必须把“更新共享变量 + notify”包在同一个锁区内，例如：
std::lock_guard<std::mutex> lk(mut);<br>data = new_value;<br>ready = true;<br>cv.notify_one();
- 如果 notify 发生在锁外，且没有其他同步机制（如
std::atomic标志配合内存序），就等于没同步
条件变量本身不难，难的是它永远不单独存在——它必须和 mutex、共享变量、谓词、内存可见性捆在一起用。少一个环节，bug 就藏在偶现的竞态里，很难复现。
