C++ 条件变量 condition_variable

condition_variable是 C 标准库中用于多线程同步的核心头文件。它主要提供了条件变量Condition Variable机制用来协调多个线程的执行顺序。简单来说它的作用就是让一个或多个线程在特定条件不满足时进入休眠阻塞等待直到另一个线程修改了共享状态并发出通知唤醒等待的线程才会继续执行。 为什么需要它在没有条件变量的情况下如果一个线程需要等待某个条件比如等待队列里有数据通常只能采用“忙等待”不断循环检查或“定时休眠检查”的方式。这两种方式都会大量浪费 CPU 资源或导致响应延迟。使用condition_variable可以让线程在没有任务时完全释放 CPU 资源进入睡眠只有在真正需要工作时才被精准唤醒从而极大提高程序的运行效率。️ 头文件里的核心组件这个头文件主要包含了以下几个关键类和函数std::condition_variable最常用的条件变量类必须配合std::unique_lockstd::mutex使用。std::condition_variable_any更通用的条件变量可以配合任何满足基本要求的锁使用但性能开销稍大。cv_status枚举类用于表示带超时的等待是否是因为超时返回的。notify_all_at_thread_exit功能函数用于安排在当前线程退出时通知所有等待的线程。⚙️ 核心工作机制条件变量的使用通常离不开互斥锁std::mutex其核心操作主要分为“等待”和“通知”两类1. 等待方消费者线程wait(lock)调用前必须先持有锁。调用后线程会自动释放锁并进入阻塞状态。当被唤醒时它会重新尝试获取锁然后继续执行。wait(lock, predicate)带谓词判断条件的等待。它等价于while(!predicate()) { wait(lock); }。强烈推荐使用这种方式因为它可以有效防止“虚假唤醒”即线程在没有收到通知的情况下意外被唤醒。wait_for/wait_until带超时时间的等待防止线程永久阻塞。2. 通知方生产者线程notify_one()随机唤醒一个正在等待该条件变量的线程适用于多个线程处理同类任务的场景如线程池。notify_all()唤醒所有正在等待该条件变量的线程适用于广播某种状态变更如程序退出信号。 经典应用场景最典型的就是生产者-消费者模型消费者线程获取锁检查队列是否为空。如果为空就调用cv.wait()释放锁并休眠等待。生产者线程获取锁向队列中放入数据然后调用cv.notify_one()或cv.notify_all()唤醒正在休眠的消费者线程。通过这种机制线程之间能够安全、高效地进行“等待-通知”的交互避免了资源的无效消耗。cv.wait(…) 到底在干什么cv.wait(lock,[]{return!data_queue.empty()||finished;});if(finisheddata_queue.empty())break;这段代码是多线程编程中消费者线程的核心逻辑通常出现在“生产者-消费者”模型中。它的主要作用是让当前线程在“没有数据可处理”且“任务未结束”时安全地进入休眠等待状态。我们可以把这段代码拆解开来详细理解️cv.wait(...)到底在干什么cv.wait(lock, []{ return !data_queue.empty() || finished; });这一行代码非常精妙它实际上在内部自动完成了一套“原子操作”和“循环检查”自动释放锁并休眠当线程运行到这里如果后面的条件不满足即队列为空且任务没结束它会自动释放传入的lock互斥锁然后让当前线程进入阻塞睡眠状态不再占用 CPU 资源。等待被唤醒线程会一直休眠直到其他线程比如生产者调用了cv.notify_one()或cv.notify_all()来唤醒它。防止“虚假唤醒”的安全检查这是使用带条件Lambda 表达式的wait最重要的原因。线程被唤醒后不会立刻往下执行而是会先重新获取锁然后再次检查Lambda 表达式里的条件!data_queue.empty() || finished是否真的成立了。如果条件依然不满足比如是操作系统导致的意外“虚假唤醒”或者被唤醒后发现队列还是空的它会继续释放锁并再次进入休眠。只有当条件真正满足时队列里有数据了或者收到了结束信号wait函数才会正式返回程序继续往下走。 条件!data_queue.empty() || finished的含义这个 Lambda 表达式规定了线程结束等待、继续工作的两个条件满足其一即可!data_queue.empty()数据队列不为空说明生产者已经生产了数据消费者可以起来干活消费数据了。finished这是一个全局的结束标志通常在程序退出或生产结束时被设为true。即使队列是空的只要收到了结束信号线程也必须醒来准备退出防止因为队列一直为空而永远死等下去。 后续的if判断是在做什么当cv.wait成功返回后线程已经拿到了锁并且确认了“要么有数据要么该结束了”。接下来的代码就是做具体的分流处理if(finisheddata_queue.empty())break;这是一个退出判断。如果线程醒来是因为收到了结束信号finished true并且此时队列里的剩余数据也都处理完了data_queue.empty()那么消费者线程就会执行break跳出循环安全地结束自己的生命。总结一下这整段代码就像是一个尽职尽责的工人消费者线程他在休息室里睡觉wait阻塞。只有在“有活干了队列有数据”或者“老板喊下班了finished”的时候才会被叫醒。醒来后如果发现是下班时间且没活干了他就直接打卡回家break否则他就去处理手头的任务。补充当线程收到“队列不为空”或“结束”的信号被唤醒后它并不是立刻、无缝地往下执行的。在cv.wait返回、程序继续往下走之前线程必须重新把刚才释放的那把锁给抢回来重新加锁。所以完整的微观过程其实是这样的释放锁并睡眠程序运行到cv.wait发现条件不满足自动释放锁线程进入休眠。被唤醒收到了通知信号或者发生了虚假唤醒。重新抢锁线程醒来后会尝试重新获取锁。如果此时其他线程比如正在往里塞数据的生产者还占着这把锁刚醒来的线程就得在cv.wait内部再次阻塞等待直到成功把锁抢到手。检查条件抢到锁后cv.wait内部会再次检查!data_queue.empty() || finished这个条件。如果条件真的满足了cv.wait才会正式返回。继续执行程序往下走此时线程是持有锁的状态可以安全地处理队列里的数据或执行退出逻辑。为什么要这么设计因为如果不重新加锁线程醒来往下执行时其他线程可能正好也在操作这个共享队列就会引发数据冲突。cv.wait保证了一旦它返回你的线程一定是拿着锁的这样你后续处理数据就是绝对线程安全的。这就是一个“释放锁 - 睡觉 - 被叫醒 - 拿回锁 - 干活”的精准闭环。使用花括号 {} 来人为限制锁的作用域// 消费者voidconsumer(){while(true){std::unique_lockstd::mutexlock(mtx);// wait 会原子地释放锁并进入等待被唤醒后重新加锁cv.wait(lock,[]{return!data_queue.empty()||finished;});if(finisheddata_queue.empty())break;intdatadata_queue.front();std::cout拿到了数据: datastd::endl;data_queue.pop();lock.unlock();// 处理数据时释放锁std::cout消费了数据: datastd::endl;}}在这个特定的代码逻辑里lock.unlock()是非常有必要的。这主要涉及到多线程编程中的**“锁粒度”和“并发性能”**问题。我们可以从以下两个角度来理解1. 避免浪费性能核心原因std::cout向控制台打印输出是一个相对非常耗时的 I/O 操作。如果不手动unlock()由于你使用了std::unique_lock锁会一直持有到当前的while循环结束即作用域结束unique_lock析构时自动释放。这意味着当线程在慢吞吞地执行两次std::cout打印时它依然死死地攥着mtx这把锁。带来的后果在打印的这段时间里其他线程比如正在拼命生产数据的生产者线程或者其他消费者线程如果想要访问data_queue或mtx就会被强制阻塞只能干等着。这会把原本可以并行工作的多线程程序强行变成“串行”执行严重拖慢整体效率。手动unlock()的好处当你把数据从队列里pop出来之后对共享队列的操作就已经结束了。此时立刻手动释放锁其他线程就能马上获取锁去处理队列里的其他任务而你的线程则可以安心地去打印日志互不干扰。2. 配合unique_lock的灵活性这正是 C 中使用std::unique_lock而不是std::lock_guard的核心优势之一。std::lock_guard只能在作用域结束时自动释放锁非常死板。std::unique_lock允许你在作用域内灵活地手动unlock()和lock()。在这个场景下这种灵活性就是为了尽早释放锁缩小临界区Critical Section的范围。 补充一个最佳实践虽然在这里手动unlock()是完全正确且必要的但在更复杂的业务逻辑中为了防止因为代码分支太多而忘记释放锁C 程序员通常会使用花括号{}来人为限制锁的作用域。例如while(true){intdata;// 用花括号把需要锁的代码包起来{std::unique_lockstd::mutexlock(mtx);cv.wait(lock,[]{return!data_queue.empty()||finished;});if(finisheddata_queue.empty())break;datadata_queue.front();data_queue.pop();// 出了这个花括号lock 自动析构锁自动释放完全不用担心忘记 unlock}// 这里的打印操作不再持有锁其他线程可以并发工作std::cout拿到了数据: datastd::endl;std::cout消费了数据: datastd::endl;}这种写法既保证了尽早释放锁又利用了 RAII 机制资源获取即初始化防止死锁是实际开发中更推荐的写法。