std::condition_variable必须与std::mutex配合使用，且wait需用std::unique_lock而非std::lock_guard；notify_one唤醒至少一个等待线程，notify_all唤醒所有，均需条件重检以防虚假唤醒。
std::condition_variable 用来让线程等待某个条件成立，它本身不带锁，必须和 std::mutex 配合使用——这是最常被忽略的关键点。
基本用法：wait + notify 的配合
一个线程调用 wait() 进入阻塞，另一个线程修改共享状态后调用 notify_one() 或 notify_all() 唤醒它。但 wait() 必须在持有互斥锁的前提下调用，且内部会自动释放锁并挂起；被唤醒后又自动重新获取锁，再继续执行。
典型写法：
- 用 std::unique_lock<:mutex> 包裹共享数据的访问
- wait 的第二个参数是 lambda 或函数对象，用于检查“醒来后条件是否真满足”（防止虚假唤醒）
- 不要用普通 while(condition) + sleep 模拟，既浪费 CPU 又不安全
为什么必须用 unique_lock，不能用 lock_guard？
因为 wait() 要求锁对象支持“临时释放并重新获取”，而 std::lock_guard 不提供 unlock() 接口，std::unique_lock 支持。这是语法硬性要求，编译器会直接报错。
立即学习“C++免费学习笔记（深入）”；
常见错误写法：std::lock_guard<:mutex> lk(mtx); cv.wait(lk, []{...}); // 编译失败
notify_one 和 notify_all 怎么选？
notify_one 唤醒**至少一个**正在 wait 的线程（具体哪个由系统调度决定），适合“一个任务只需一个消费者处理”的场景，比如生产者-消费者中一个新任务来了，唤醒一个空闲工作线程即可。
notify_all 唤醒所有等待线程，适合“状态变化影响所有观察者”的情况，比如全局开关关闭、资源批量就绪等。但注意：被唤醒的线程仍需再次检查条件，因为可能多个线程同时竞争并发现条件已失效。
- 多数情况下优先用 notify_one，更轻量、避免惊群效应
- notify_all 不等于“全部立即执行”，只是解除阻塞，之后仍要抢锁、重判条件
别忘了异常安全和生命周期管理
如果等待线程在 wait 中被中断（如线程被 joinable 后销毁），或 notify 线程提前退出导致 condition_variable 析构，行为未定义。所以：
- 确保 notify 线程比 wait 线程活得久，或用 shared_ptr 管理同步对象（较少见）
- 在析构前手动 notify_all，让所有等待线程有机会退出循环
- wait 的 lambda 尽量不抛异常；若可能抛，用 try/catch 包住 wait 调用
基本上就这些。用熟了就是三步：加锁 → 判条件 → wait 或操作 → 解锁 → notify。不复杂但容易忽略细节。
