我记得第一次把条件变量用进生产代码是在一个任务分发模块里。当时为了等一个初始化完成的标志位写了个while(!ready) std::this_thread::yield();的循环本地跑得好好的扔到多核机器上跑了半天CPU 占用直接顶到一核满载运维那边以为是死循环报了过来。后来换成 C11 的std::condition_variableCPU 是下来了但紧接着又踩了另一个更隐蔽的坑——一个测试用例跑几千次才挂一次挂的表现是线程永久卡死。查了两天才定位到是先判断条件、后进入 wait的顺序出了问题条件在两行代码之间被改掉通知发出去了等待方却还没开始等。这篇就围绕condition_variable的wait/notify和mutex的搭配来讲。它的定位很清楚解决一个线程要等某个状态成立才继续干活的问题同时不浪费 CPU。适合已经会用std::thread和std::mutex、准备往线程间协作迈一步的人也适合已经写过但被时序问题折磨过、想把机制彻底搞明白的人。下面这些内容偏实战会从底层动作拆到成品队列再把几个典型的时序坑一个个摆出来。1. 从一段轮询代码切入条件变量替换掉的到底是什么1.1 忙等检测标志位在真实项目里的代价新手写线程间等待第一反应基本都是轮询。开一个bool或者std::atomicbool一个线程负责置位另一个线程在循环里反复读。逻辑上没毛病问题是这个循环在条件还不成立的那段时间里一直在消耗 CPU 时间片。单看一个线程好像无所谓但如果有几十个这样的等待线程或者这段代码跑在核心数有限的容器里性能就会被白白吃掉。更麻烦的是延迟和开销的取舍。加个sleep_for(10ms)能降 CPU但响应延迟就被拉到了十毫秒量级把睡眠调短CPU 又上去了。这是个没法两全的调节旋钮本质上是因为轮询模型里等待方根本不知道条件什么时候会变它只能靠不停地问。条件变量解决的正是这个信息不对称——它让等待方在条件不成立时彻底交出 CPU由改变条件的一方主动把它叫醒。这里有个容易被忽略的细节轮询代码在判断和读取之间如果没有内存序或锁的保护还可能读到过期值。用atomic加合适的 memory order 能修正但那又是另一套复杂度。条件变量天然要求配一把mutex互斥和可见性一起给你解决了。1.2 mutex 管互斥、condition_variable 管等待职责不能混很多人第一次看wait(lock)的签名会愣一下为什么等待还要传一把锁进去这不是把两个东西搅在一起了吗。实际上这俩职责分得很清楚。mutex保证的是同一时刻只有一个线程能碰这段共享状态防止数据竞争condition_variable保证的是条件不成立时线程让出 CPU条件成立时被叫醒。关键在于条件本身也是一份共享状态比如队列是否为空、任务是否完成。这份状态必须被mutex保护否则读写会打架。而等待这个动作必须建立在我已经确认过条件不成立的基础上否则就会丢失唤醒。两件事绑在一起才产生了wait(lock)这个看起来别扭但逻辑严密的接口。你可以把它想成银行柜台mutex是柜台的窗口钥匙一次只有一个人能站到窗口前condition_variable是叫号系统没轮到你的时候你在等候区坐着不占窗口也不占 CPU柜台空了自然会叫你。这个类比在后面的坑里还会用到——如果有人在等候区听不到叫号那一定是叫号和就座之间的衔接出了问题。2. wait 的三步动作解锁、阻塞、重新加锁之间的原子性2.1 为什么先判断再等待必须和 mutex 绑在一起wait(lock)内部做的动作可以概括成三步释放lock持有的mutex、把当前线程挂起阻塞、被唤醒后重新获取mutex再返回。标准明确要求第一步和第二步之间是原子的也就是解锁并阻塞这个整体不可被打断。这条保证是条件变量能正确工作的基石。假设没有这条原子性等待线程先解锁然后在真正挂起之前被调度出去此时另一个线程修改了条件、发出notify但等待线程还没进等待队列通知就丢了等它回来挂起条件其实早就成立了可它已经错过了通知于是永久阻塞。这个窗口在真实机器上窄得几乎看不见但只要并发压力够大、调度够频繁就一定会撞上。所以正确写法的核心是持锁检查条件条件不成立就在持锁状态下进入 wait。因为通知方要修改条件必须先拿到同一把mutex等待方在进入 wait 之前一直持锁通知方根本插不进来。这就把检查—等待之间的空隙彻底封死了。// 正确持锁检查持锁进入等待 std::unique_lockstd::mutex lock(mtx); while (!ready) { cv.wait(lock); } // 到这里 ready 为真且持有锁要注意wait需要的是std::unique_lockstd::mutex不是std::lock_guard因为等待过程需要反复解锁和加锁lock_guard没有这个能力。这是新手编译报错的第一个坎接口设计上算是强制你意识到锁在等待期间会被释放这件事。2.2 wait 的谓词重载到底帮你省掉了什么手写while (!cond) cv.wait(lock);是标准范式但 C11 还提供了一个重载cv.wait(lock, pred)。它等价于while (!pred()) cv.wait(lock);一行写法背后就是那个循环。为什么值得单独说因为省掉的那个while恰恰是最常被偷工减料的地方。很多人会写if (!ready) cv.wait(lock);看着更自然实际上丢掉了循环。这样写的问题在于两种情况一是虚假唤醒二是多个等待方时的通知错配。虚假唤醒是指线程在没有收到任何notify的情况下从wait返回标准允许这种情况发生底层可能因为信号处理、实现细节等原因被唤醒。如果你的代码只在wait外面判断一次被虚假唤醒后就会直接往下走带着一个并不成立的条件去操作共享数据行为完全不可预期。用谓词版本还有个好处是语义清晰条件表达式直接写进wait里别人一眼能看出这个线程在等什么。我现在的习惯是把条件抽成一个 lambda 或者直接写成员判断绝不用裸的if包wait。// 推荐写法 cv.wait(lock, [this] { return !queue_.empty() || done_; });另外提一句condition_variable_any它能配合任意满足 BasicLockable 的类型比如std::shared_mutex的独占锁或者是自定义的锁。代价是内部会有额外的类型擦除和同步开销所以标准库的condition_variable默认只支持unique_lockstd::mutex性能更好。能用前者就别用后者除非你真的需要自定义锁。2.3 notify 放在锁内还是锁外两种写法各自的代价这是个老生常谈但确实有讲究的问题。代码长这样// 写法 A锁内修改、锁内通知 { std::lock_guardstd::mutex lock(mtx); queue_.push(task); cv.notify_one(); } // 写法 B锁内修改、锁外通知 { std::lock_guardstd::mutex lock(mtx); queue_.push(task); } cv.notify_one();写法 A 的问题是被唤醒的线程从wait返回时要重新抢mutex而此刻这把锁还在通知方手里它只能又一次阻塞在锁上等通知方退出作用域才真正能干活。这种情况被戏称为刚起床又被打晕。在高频调用的路径上这会额外增加一次上下文切换的成本。写法 B 把通知放到锁外被唤醒线程能直接拿到锁开始工作效率更好。那为什么不干脆一律用 B因为要小心一个边界如果cv和mtx的生命周期依赖于某个对象而这个对象可能在线程处理完之前被销毁那么锁外通知就有极小的概率发生通知时条件变量已经析构的问题。写库代码、写那种对象随时可能被关闭的场景时锁内通知更保守也更安全。我的选择标准很简单普通生产者消费者队列用 B追求吞吐涉及对象生命周期销毁、等待线程必须有序退出的用 A 换一份安心反正退出路径不在热路径上。3. 手写一个生产者-消费者队列把示例代码写到能进仓库的程度3.1 队列骨架与 push/pop 的等待条件书本上的例子通常省略了关闭逻辑和异常安全直接拿去用会出事。我给个自己仓库里长期用的版本结构简单但把该处理的都处理了。#include condition_variable #include mutex #include queue #include optional template typename T class BlockingQueue { public: explicit BlockingQueue(std::size_t capacity 1) : capacity_(capacity) {} void push(T value) { std::unique_lockstd::mutex lock(mtx_); // 队列满则等注意也要等关闭状态 not_full_.wait(lock, [this] { return queue_.size() capacity_ || closed_; }); if (closed_) return; queue_.push(std::move(value)); lock.unlock(); not_empty_.notify_one(); } std::optionalT pop() { std::unique_lockstd::mutex lock(mtx_); not_empty_.wait(lock, [this] { return !queue_.empty() || closed_; }); if (queue_.empty()) return std::nullopt; // 关闭且已排空 T value std::move(queue_.front()); queue_.pop(); lock.unlock(); not_full_.notify_one(); return value; } void close() { { std::lock_guardstd::mutex lock(mtx_); closed_ true; } not_empty_.notify_all(); not_full_.notify_all(); } private: std::mutex mtx_; std::condition_variable not_empty_; std::condition_variable not_full_; std::queueT queue_; std::size_t capacity_ 1; bool closed_ false; };这里的两个条件变量分别对应空和满两个等待条件。用两个而不是一个是为了避免notify_one唤醒一个条件并不满足的线程。想象只有一个cv生产者入队后notify_one唤醒的却可能是一个在等队列不满的生产者它醒来发现还是满的又睡回去而真正该醒的消费者还在睡。用两个cv各自负责一条条件线配合notify_one就够了。pop返回std::optionalT而不是直接T是为了表达拿不到有效数据这个状态。如果队列关闭且已经空了返回空调用方据此退出循环。也有人用bool pop(T out)的写法各有取舍关键是别让调用方分不清拿到空值和队列关了。3.2 关闭流程让所有等待线程有序退出关闭是个特别容易漏的环节。线程池在析构时如果工作线程还阻塞在pop里close就不该被忽略更不能直接析构队列。流程必须是这样先置关闭标志再广播通知所有等待者最后 join 线程等所有线程确实退出了才销毁队列。置标志和广播之间为什么必须分两步、而且要持锁置标志因为如果先通知后置标志被唤醒的线程可能重新检查条件发现closed_还是 false于是又睡回去了之后再也没人叫它。先改状态再通知的顺序不能反。close里我对两个条件变量都做了notify_all因为等待方可能分别在等非空和不满都需要被叫醒去检查关闭标志。notify_all在这里不是性能问题关闭本来就只发生一次。还有个细节pop在关闭且队列非空时我选择继续把剩余数据返回直到排空才返回空。这对应优雅关闭语义——已经入队的任务要处理完。如果你的场景要求立刻停止那就在检查时优先判断closed_丢弃剩余数据。两种语义都合理但一定要在自己的项目里写清楚别让调用方猜。3.3 notify_one 与 notify_all 的取舍notify_one唤醒一个等待线程notify_all唤醒全部。选的依据不是性能直觉而是这次状态变化能满足几条等待条件。生产者在队列从空变非空时理论上只需要一个消费者来完成这次消费用notify_one就够。反过来用notify_all十个消费者同时醒来抢一把锁九个白跑一趟抢锁的开销白白浪费。但有两种情况notify_one会出问题一是多个线程在等不同的条件却共用同一个cv唤醒的可能不是满足条件那个二是条件变化能同时满足多个等待者比如关闭标志置位、批量放行。判断方法很简单问自己这次状态变化后最多有几个线程可以立刻继续往下走。如果是一个notify_one如果是多个或者说不清notify_all。别为了省那点唤醒开销把逻辑搞错正确性永远优先。4. 踩坑实录那些跑几千次才崩一次的时序问题4.1 丢失唤醒条件检查和 wait 之间被插了一刀我遇到最典型的一次代码大致是这样// 错误示范 bool ready false; std::mutex mtx; std::condition_variable cv; void worker() { std::unique_lockstd::mutex lock(mtx); if (!ready) { // 在锁里检查没错 lock.unlock(); // 自己把锁放了 cv.wait(lock); // 这两行之间ready 可能已被改成 true 并通知过 } }看起来只是多此一举地手动解锁实际上把原子窗口彻底破坏了。手动unlock和进入wait之间是一个真实存在的空隙通知方在这段时间里拿到锁、改状态、发通知全部命中空档。等到wait真正开始它等的是一个永远不会再来的通知。排查这类问题的思路是这样先确认线上线程卡在哪里用调试器 attach 上去看栈帧如果多个线程都停在condition_variable::wait上而条件明明已经满足那基本就是通知早于等待。反过来再去看等待路径上有没有任何在检查条件和进入 wait 之间释放锁的动作包括手动 unlock、包括用一个临时lock_guard包住条件检查。修复就是回到标准范式别做多余的事std::unique_lockstd::mutex lock(mtx); cv.wait(lock, []{ return ready; });顺带说一句这类 bug 的复现特征很有辨识度单线程跑不出来加了日志就消失跑几千次才中一次。看到这几个特征组合优先怀疑丢失唤醒和虚假唤醒。4.2 谓词省略导致的虚假唤醒前面提过if (!ready) cv.wait(lock);的问题这里补一个更隐蔽的变体条件判断本身写对了但判断的内容和实际使用的内容不一致。// 有问题的写法 std::unique_lockstd::mutex lock(mtx); cv.wait(lock, []{ return !queue_.empty(); }); T value queue_.front(); // 这里没锁保护另一个消费者可能已经弹走了 queue_.pop();等等问题不在wait而在结构。如果wait返回后紧接着释放了锁或者用了错误的锁对象去保护后续访问条件就会在使用过程中被别的线程改掉。wait只保证返回时条件成立不保证离开作用域前条件一直成立。所以从wait返回到真正消费数据之间锁必须一直持有。另一种常见变体是把谓词写成对副本的判断bool flag !queue_.empty(); // 锁外读已经是错的 cv.wait(lock, []{ return flag; }); // 谓词读的是永远不会变的副本这种写法在代码评审里特别难发现因为看起来条件判断被抽出去了挺整洁。实际上整个谓词要么恒真要么恒假wait变成空转或者永久阻塞。我现在的要求是谓词里只允许出现成员变量访问和常量比较不允许出现任何预计算的结果。4.3 共享状态在锁外被读写条件变量只管叫醒不管数据保护。这条边界模糊掉就会出现线程确实被叫醒了但读到的数据是脏的。// 错误done_ 在锁外被改 void finish() { done_ true; // 裸写 cv.notify_all(); }done_是个普通bool这样写既是数据竞争也让编译器有权把它优化进寄存器等待线程可能永远读到旧值。虽然实际中很多编译器不会这么激进但这是货真价实的未定义行为换个编译选项或者换台机器就可能翻车。修正方式只有一条改动任何被wait谓词引用的状态必须持有同一把mutex。把它做成习惯——只要一个变量会出现在某个wait的谓词里它所有的写操作都在锁内完成没有例外。4.4 析构时还有线程在 wait 上挂着对象析构的顺序问题比数据竞争更直接condition_variable析构时如果还有线程在wait上行为未定义实际表现通常是崩溃或者静默卡住。常见场景是任务类里持有队列主线程觉得任务做完了直接让对象析构工作线程还在pop里等新任务。修法不是加个sleep等一等而是走完整的关闭协议置标志、通知、join三步一步不能少。join这步尤其不能省它是唯一能保证这个线程已经彻底结束了的手段。还有一个容易忽略的变体对象是shared_ptr某个线程持有一份引用主线程把最后一份引用释放了析构发生在那个线程里而它自己此刻正在等这个对象的条件变量。这种自引用销毁的循环很隐蔽排查时看崩溃栈经常是析构函数里调用了wait相关的东西。解法是明确对象的所有权别让工作线程持有自己所属对象的强引用。我的检查清单里有一条任何包含condition_variable的类析构函数第一行必须是断言没有活着的等待线程或者干脆在里面做一次close notify_all再依赖外层的join保证。宁可多一次通知也不要赌运气。4.5 超时版本返回值被忽略带超时的wait_for/wait_until有个重载返回bool带谓词不带谓词的版本返回std::cv_status。很多人直接调用谓词版本却忽略返回值以为超时和正常唤醒是一样的结果把超时当成条件成立拿去处理一份并不存在的数据。// 有问题的写法 cv.wait_for(lock, std::chrono::seconds(1), []{ return done_; }); consume(); // 超时了也会走到这里 // 正确 bool ok cv.wait_for(lock, std::chrono::seconds(1), []{ return done_; }); if (!ok) { // 超时分支条件是假的 return; } consume();还有cv_status那条路径也不能忽略std::cv_status::timeout表示超时no_timeout表示被通知。如果底层条件是没有新数据就做点别的事必须显式处理超时分支不能让它悄悄流到正常路径里。另外提醒一句超时判断本身可能因为系统时钟跳变而不准需要严格单调计时的场景用wait_until配steady_clock更稳妥。这个坑不是条件变量独有的但因为它藏在计时参数里很容易被忽略。5. 什么时候不该用条件变量几种替代方案的适用边界5.1 原子变量自旋与条件变量的场景分界条件变量不是所有等待场景的最优解。它的唤醒涉及内核态从阻塞到被调度回来有微秒级甚至更高的延迟。如果等待的时间极短、发生频率极高阻塞和唤醒的开销可能超过等待本身。典型的反例是一个高频 tick 的自旋等待生产者每秒推几十万次消费者几乎永远不用等超过几微秒。这种场景下用std::atomic加短自旋配合std::this_thread::yield()让出时间片反而更划算。判断依据可以粗略地看平均等待时长微秒级以下考虑自旋毫秒级以上用条件变量中间地带实测之后再定。不过自旋有它的代价一是 CPU 空转二是需要自己处理内存序。这部分复杂度在条件变量里是被封装掉的。所以我的默认选择依然是条件变量只有在性能剖析明确指向唤醒开销、且等待确实极短的情况下才换成自旋。5.2 future/promise 与信号量各自解决的形状std::future和std::promise解决的是一次性结果传递的场景。一个线程算出一个值另一个线程等着拿这件事用条件变量也能做但要自己维护标志、锁、通知三件套而future一行get()就完了还自带异常传递。如果等待是一次性的、只为拿一个结果优先用future如果是反复等待同一个条件成立条件变量更合适。std::counting_semaphore这一套在高版本标准里提供了计数型资源许可的语义把有几个槽位可用这件事直接建模成计数器省掉了自己写谓词判断的功夫。如果等待的本质就是资源计数增减用信号量表达意图更清楚。不过兼容性要考虑如果项目还卡在较旧的标准上条件变量仍然是最通用的方案。再补一个latch和barrier它们处理的是多个线程到齐了再一起走这种集体同步条件变量当然也能拼出来但用一次性的latch或可循环的barrier语义更直白也不容易写错计数。选型的思路其实就一句话先看你等的是什么形状——等一个结果、等一个计数、等一批线程到齐、还是等一个会反复变化的状态形状对上了代码自然就短。最后分享一个小技巧。调试条件变量相关问题时我会临时在wait前后和notify前后各打一条带线程 id 和时间戳的日志然后用std::chrono::steady_clock记录两边的相对顺序。日志本身会影响时序所以只用来确认通知是否发生在等待建立之前这个定性判断不用来测性能。真正定位之后立即把日志删掉别留在热路径上——我见过因为调试日志太多反而掩盖了原始问题的情况。