文章目录0.引言1.核心组件与基本 API2.生产者-消费者示例3.为什么 wait必须与互斥锁配合使用4.notify_one 与 notify_all 的区别5.谓词版本的 wait 为什么更安全6. 小结0.引言在多线程编程程序中线程之间经常需要协同工作。常见的一种场景是一个线程需要等待某个条件满足再继续执行。例如消费者线程等待队列非空然后取出数据工作线程等待某个标志位被设置然后开始处理任务。如果直接用最简单的轮询busy waiting来实现// 消费者线程while(queue.empty()){// 什么都不做继续循环}// 退出循环后队列非空取出数据这种写法的问题很明显CPU 会一直空转浪费资源如果系统负载高这种空转可能导致其他线程得不到执行机会。条件变量std::condition_variable正是为了解决这个问题而生的。它允许线程在条件不满足时休眠将 CPU 让给其他线程直到条件满足时被唤醒。这是一种高效的线程同步机制。1.核心组件与基本 APIC 标准库提供了两个条件变量类std::condition_variable只与 std::mutex 配合使用。std::condition_variable_any可与任何满足互斥体概念的对象配合但开销更大。在绝大多数情况下我们使用 std::condition_variable 即可。主要成员函数2.生产者-消费者示例我们来实现一个最简单的生产者-消费者模型生产者线程向队列中放入数据并通知消费者。消费者线程等待队列非空然后取出数据。#includeiostream#includethread#includemutex#includecondition_variable#includequeue#includechronostd::queueintg_queue;// 共享数据队列std::mutex g_mutex;// 保护队列的互斥锁std::condition_variable g_cv;// 条件变量voidproducer(){for(inti0;i10;i){{std::lock_guardstd::mutexlock(g_mutex);g_queue.push(i);std::coutProduced: istd::endl;}// 离开作用域自动解锁g_cv.notify_one();// 通知一个消费者线程std::this_thread::sleep_for(std::chrono::milliseconds(100));}}voidconsumer(){while(true){std::unique_lockstd::mutexlock(g_mutex);// 等待直到队列非空条件满足g_cv.wait(lock,[]{return!g_queue.empty();});// 条件满足取出数据intvalueg_queue.front();g_queue.pop();std::coutConsumed: valuestd::endl;lock.unlock();// 可选提前解锁// 模拟消费耗时std::this_thread::sleep_for(std::chrono::milliseconds(150));}}intmain(){std::threadt1(producer);std::threadt2(consumer);t1.join();// 为了让消费者看到结束此处简单等待实际项目可使用哨兵值std::this_thread::sleep_for(std::chrono::seconds(1));// 注意这里没有优雅退出只是示例实际应该设置停止标志return0;}关键点解释生产者使用 std::lock_guard 来锁定 g_mutex在修改队列后立即释放锁然后调用 notify_one()。这样唤醒时消费者线程可以立刻获取锁。消费者使用 std::unique_lock而不是 lock_guard因为 wait 需要在线程阻塞期间解锁唤醒后再重新锁定unique_lock 支持这种操作。wait 的谓词版本 g_cv.wait(lock, []{ return !g_queue.empty(); }) 等价于while(!g_queue.empty()){g_cv.wait(lock);}它会在条件不满足时持续等待即使被虚假唤醒spurious wakeup也会重新检查条件。3.为什么 wait必须与互斥锁配合使用这是一个常见的问题为什么不能单独使用条件变量为什么 wait 必须接受一个已经锁定的 unique_lock考虑一个没有锁的伪代码实现// 错误示例没有使用互斥锁if(queue.empty()){cv.wait();// 假设有这样的 API}假设线程 A 执行到 if (queue.empty()) 判断为真正准备进入 wait但此时操作系统切换到了生产者线程 B。B 修改了队列使其非空并调用了 notify_one()。由于 A 还没有进入 wait这个通知就丢失了。接着 A 才进入 wait它将永远等下去因为没有人再通知它了。这就是经典的 “丢失唤醒” 问题。解决办法是将条件检查和进入等待这两个步骤原子化。互斥锁实现了这一点wait 内部会原子地完成“解锁 阻塞”两个动作同时保证条件检查在锁的保护下完成。具体过程如下1线程在调用 wait 之前已经持有锁。2wait 内部首先检查条件谓词版本会先调用谓词如果不满足则执行下面的步骤。3原子地释放锁 阻塞线程。4当被唤醒后wait 重新获取锁然后返回或再次检查谓词。这样从条件检查到进入休眠之间没有空隙通知不会丢失。因此wait 必须与互斥锁配合并且锁必须由 std::unique_lock 持有因为 lock_guard 不支持中途释放锁。4.notify_one 与 notify_all 的区别notify_one()唤醒一个等待的线程如果有多个由调度器决定唤醒哪一个。适用于只需一个线程处理新任务的场景可以减少“惊群效应”。notify_all()唤醒所有等待的线程。适用于所有线程都需要响应某个状态变化比如程序结束标志。在生产者-消费者模型中如果只有一个消费者notify_one 就足够了。如果有多个消费者且每次生产一个数据通常也使用 notify_one因为只有一个消费者能获得数据其他被唤醒的线程会再次进入等待造成不必要的上下文切换。5.谓词版本的 wait 为什么更安全上面的示例中我们使用了 g_cv.wait(lock, []{ return !g_queue.empty(); }); 而不是直接调用 wait(lock) 再自己检查。理由有两个1自动处理虚假唤醒即使线程被虚假唤醒谓词会被重新检查如果不满足会继续等待避免了错误执行。2代码更简洁将条件检查与等待逻辑封装在一起减少了出错可能。在 C 标准中wait(lock, pred) 等价于while(!pred()){wait(lock);}因此它已经包含了必要的循环。6. 小结条件变量解决了线程间高效等待的问题避免了 CPU 空转。基本用法互斥锁 条件变量等待条件满足。wait 必须与 std::unique_lock 配合用于原子地释放锁并阻塞。使用 notify_one 或 notify_all 唤醒线程。始终使用谓词版本的 wait以正确处理虚假唤醒。下一篇我们将深入探讨条件变量的超时机制。更多深入内容欢迎了解C/Linux/ 数据库内核 | 底层开发 AI 实战圈——12 个月系统落地从原理到工业级实战搭建你的核心技术壁垒