c++条件变量condition_variable怎么用_c++多线程通信实现【详解】

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 和清晰的状态设计，才能写出健壮的多线程逻辑。

# ai # c++ # 区别 # red # 循环 # Lambda # 线程 # 多线程 # 对象 # 事件 # 解锁 # 加锁 # 的是 # 是一个 # 是个 # 多个 # 只需 # 会在 # 有机会 # 第二个

返回目录在线咨询

上一篇：小饭店怎样做网络营销策略,小饭店怎么做好营销？谁有小诀窍？
下一篇：微信小程序遇到修改数据后页面不渲染的问题解决

您的项目需求