std::condition_variable 必须与 mutex 配合使用，通过循环检查加锁保护的共享条件，wait() 自动处理解锁/重锁，notify_one() 或 notify_all() 用于唤醒等待线程，需注意通知时机与虚假唤醒防护。
条件变量 std::condition_variable 本身不带“条件”，它只是让线程能安全地等待某个共享状态改变；真正起作用的是你用互斥锁保护的、手动检查的那个“条件”。用错的关键，往往不是不会调用 wait() 或 notify_one()，而是忘了：必须在循环中检查条件、必须用锁保护共享数据、通知和等待必须看到同一把锁。
核心配合：必须和 mutex 一起用
条件变量不能单独使用，它依赖 std::mutex 来保护被等待的共享状态。典型结构是：
- 加锁（
lock_guard或unique_lock） - 检查条件（比如
queue.empty()） - 若不满足，调用
cv.wait(lock, predicate)—— 它会自动解锁并挂起，被唤醒时自动重新加锁 - 条件满足后继续执行临界区逻辑
注意：wait() 的第二个参数是个可调用对象（Lambda 最常用），它会在每次被唤醒后重新求值；返回 false 就继续等，true 才退出等待。这天然支持「虚假唤醒」防护。
通知时机：notify_one 和 notify_all 的区别
notify_one() 唤醒**至少一个**正在 wait 的线程（具体哪个由系统调度决定）；notify_all() 唤醒所有等待线程。
立即学习“C++免费学习笔记（深入）”；
- 生产者-消费者模型中，通常一个产品只需一个消费者处理 → 用
notify_one() - 多个线程在等同一个全局事件（如“初始化完成”）→ 用
notify_all() - 避免惊群效应或资源竞争时，优先选
notify_one()
通知可以在锁内或锁外发，但推荐在锁内通知（尤其涉及状态更新时），确保通知与状态变更的原子性可见。
典型场景：生产者-消费者队列
下面是一个安全的无界队列示例片段：
std::queue<int> data_queue; std::mutex mtx; std::condition_variable cv; // 消费者 void consumer() { std::unique_lock<std::mutex> lock(mtx); cv.wait(lock, []{ return !data_queue.empty(); }); // 循环检查 int val = data_queue.front(); data_queue.pop(); lock.unlock(); // 显式释放锁，避免阻塞生产者 process(val); } // 生产者 void producer(int val) { std::unique_lock<std::mutex> lock(mtx); data_queue.push(val); lock.unlock(); // 先解锁再通知，减少持有时间 cv.notify_one(); // 通知一个等待的消费者 }关键点：消费者用 wait() 自动处理锁的释放与重入；生产者先改数据再通知；双方都只在临界区内访问 data_queue。
常见坑和注意事项
- 别用普通
lock_guard调wait()：它不可移动、不可转移，而wait()需要能临时释放并重新获取锁 → 必须用std::unique_lock<:mutex></:mutex> - 不要在析构前忘记 notify：比如线程池关闭时，应发
notify_all()让所有等待线程有机会退出 - 条件检查必须在锁保护下进行：否则可能读到过期值，导致死等或跳过通知
- 避免 notify 早于 wait：如果先
notify后wait，该次通知就丢失了 → 所以总是先检查条件再 wait
基本上就这些。条件变量不是万能通信机制，它适合“等某事发生”，不适合传递数据或做复杂同步；搭配 mutex 和清晰的状态设计，才能写出健壮的多线程逻辑。