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() 唤醒所有等待线程。
- 生产者-消费者模型中，通常一个产品只需一个消费者处理 → 用
notify_one()
- 多个线程在等同一个全局事件（如“初始化完成”）→ 用
notify_all()
- 避免惊群效应或资源竞争时，优先选
notify_one()
通知可以在锁内或锁外发，但推荐在锁内通知（尤其涉及状态更新时），确保通知与状态变更的原子性可见。
典型场景：生产者-消费者队列
下面是一个安全的无界队列示例片段：
std::queue data_queue;
std::mutex mtx;
std::condition_variable cv;
// 消费者
void consumer() {
std::unique_lock 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 lock(mtx);
data_queue.push(val);
lock.unlock(); // 先解锁再通知，减少持有时间
cv.notify_one(); // 通知一个等待的消费者
}
关键点：消费者用 wait() 自动处理锁的释放与重入；生产者先改数据再通知；双方都只在临界区内访问 data_queue。
常见坑和注意事项
-
别用普通
lock_guard 调 wait()：它不可移动、不可转移，而 wait() 需要能临时释放并重新获取锁 → 必须用 std::unique_lock<:mutex>
-
不要在析构前忘记 notify：比如线程池关闭时，应发
notify_all() 让所有等待线程有机会退出
-
条件检查必须在锁保护下进行：否则可能读到过期值，导致死等或跳过通知
-
避免 notify 早于 wait：如果先
notify 后 wait，该次通知就丢失了 → 所以总是先检查条件再 wait
基本上就这些。条件变量不是万能通信机制，它适合“等某事发生”，不适合传递数据或做复杂同步；搭配 mutex 和清晰的状态设计，才能写出健壮的多线程逻辑。
件变量不能单独使用，它依赖