C++ condition_variable 详解：wait、notify_one 与 notify_all 机制

核心概念：为何需要 condition_variable？

在使用 std::condition_variable 之前，通常存在这样一个需求：主线程或工作线程 A 需要等待另一个线程 B 完成某项操作（例如向容器添加数据），然后才能继续处理这些数据。如果仅依靠轮询检查状态，会严重浪费 CPU 资源；而简单的互斥锁只能防止并发访问，无法实现“等待条件发生”的功能。

condition_variable 允许线程休眠，直到收到通知或被显式唤醒。它与互斥量（Mutex）紧密配合，确保在检查和进入等待状态之间的原子性，从而避免竞态条件。

基础用法：wait 与 notify_one 的工作流程

std::condition_variable 最常用的接口是 wait 和 notify_one。以下是一个基础的生产者-消费者模型，展示数据如何从列表一端注入，另一端取出。

第1步：定义共享数据结构与同步对象

首先需要定义一个类来管理共享数据和同步原语：

#include <iostream>
#include <mutex>
#include <list>
#include <thread>
using namespace std;

class Obj {
private:
    list<int> myList;
    condition_variable var;
    mutex tex;
public:
    // 生产者：向列表添加数据
    void inToList() {
        for (int i = 0; i < 100; i++) {
            unique_lock<mutex> cur(tex);
            myList.push_back(i);
            cout << this_thread::get_id() << "正在向list中添加数据: " << i << endl;
            var.notify_one(); // 唤醒一个等待的消费者
        }
    }

    // 消费者：从列表取出数据
    void outFromList() {
        while(true) {
            unique_lock<mutex> cur(tex);
            // 等待直到列表不为空
            var.wait(cur, [this] {
                return !myList.empty();
            });
            
            int comb = myList.front();
            myList.pop_front();
            cout << this_thread::get_id() << "正在取出数据: " << comb << endl;
        }
    }
};

int main() {
    Obj obj;
    thread thread1(&Obj::outFromList, &obj); // 消费者
    thread thread2(&Obj::inToList, &obj);   // 生产者
    thread1.join();
    thread2.join();
    cout << "这里是主线程" << endl;
}

第2步：理解 wait 的内部逻辑

在 outFromList 中，var.wait(cur, lambda) 的执行过程如下：

1. 检查条件：首先计算 lambda 表达式的返回值。如果返回 true，则直接跳过等待，持有锁继续执行后续代码。
2. 休眠与释放锁：如果返回 false，线程会将自身加入等待队列，并释放绑定的锁（cur）。此时，其他线程可以获得该锁并修改共享数据。
3. 被唤醒：当调用 notify_one 或 notify_all 时，阻塞的线程会被唤醒。但在重新执行 lambda 之前，它会尝试重新获取锁。
4. 重新验证：一旦获得锁，再次执行 lambda 表达式。这种“等待-释放-通知-重新获取-验证”的过程是为了防御虚假唤醒（Spurious Wakeups）。即使没有收到通知，线程也可能意外醒来，因此必须通过 Lambda 重新确认条件是否真正满足。

关键陷阱：为什么 notify_one 可能无效？

很多开发者认为，只要调用了 notify_one，等待中的线程就会立即醒来并执行。这在某些情况下是错误的，主要原因在于锁的竞争与持有时间。

第3步：重现通知失效场景

如果在消费者线程中，取出数据后还需要进行耗时操作（如网络请求、复杂计算），且在此过程中未释放锁，那么生产者发送的通知可能会错过消费线程的准备状态。

// 修改后的消费者逻辑
void outFromList() {
    while(true) {
        unique_lock<mutex> cur(tex);
        var.wait(cur, [this] { return !myList.empty(); });
        
        int comb = myList.front();
        myList.pop_front();
        
        cur.unlock(); // 关键：提前释放锁
        
        // 模拟耗时操作
        cout << this_thread::get_id() << "正在取出数据: " << comb << endl;
        chrono::seconds tim(2);
        this_thread::sleep_for(tim);
    }
}

在上述代码中，我们在取出数据后立即调用了 cur.unlock()。这允许生产者在消费者处理数据的同时，继续快速向列表中插入更多数据。如果没有这一步，生产者的每次 push_back 都会阻塞，直到消费者睡眠结束，这将导致极大的性能浪费且失去多线程的意义。

然而，这里也存在一个潜在风险：通知丢失。如果 notify_one 发生时，消费者正处于解锁后的睡眠状态（即尚未进入下一次 wait 的等待队列），该通知将不会被记录，消费者将继续沉睡，直到下一个生产者发出通知。虽然在这个简单的循环例子中不会出错（因为最后会有通知），但在更复杂的逻辑中，必须确保先检查状态，再决定是否需要等待，或者始终等待。wait 函数会自动处理这种情况，但前提是调用结构正确。

图片展示了当消费者耗时较长时，生产者线程可能在等待期间累积了大量数据，而消费者在获取锁后才逐步处理。这证明了多线程并非严格的宏观顺序执行，而是基于锁资源的并行调度。

高级用法：notify_all 的使用场景

与 notify_one 不同，notify_all 会唤醒所有处于等待状态的线程。由于同一时刻只有一个线程能持有锁，被唤醒的线程将排队竞争锁。只有获得锁且 Lambda 表达式返回 true 的线程才会继续执行，其余线程在重新获取锁失败或条件不满足后，通常会再次进入等待（取决于具体的 Wait 实现模式）。

适用场景：

• 资源完全释放：例如线程池中的所有工作线程都在等待任务提交，当一个任务到来时，应唤醒所有空闲线程，让它们通过竞争获取任务。
• 条件变化影响多个消费者：如果多个线程都在等待不同的部分资源，而某个事件触发了所有相关条件的变化，则使用 notify_all 避免遗漏。

注意：在大多数简单的单对多依赖场景（如一个生产者对应多个消费者，或反之），notify_one 通常更高效，因为它避免了不必要地唤醒大量暂时无法工作的线程（Thundering Herd Problem）。

总结与最佳实践

1. 始终使用 Predicate（Lambda）：永远不要单独调用 wait(lock)，务必传入一个判断条件的 Lambda 表达式，以防御虚假唤醒和处理并发竞争。
2. 明确锁的生命周期：在进行耗时操作前，尽早释放锁，以提高系统吞吐量。利用 unique_lock 的作用域或手动 unlock() 来控制。
3. 理解通知的即时性局限notify_one 只是提示等待线程去竞争锁，并不保证立即执行。如果竞争不过其他线程，通知的效果可能被延后消化。
4. 选择正确的通知方式：一对一或稀疏依赖用 notify_one，全局状态变更用 notify_all。

以上就是 C++ 中利用 condition_variable 实现多线程同步与协调的详细内容，更多关于 C++ 并发编程与线程安全的资料请关注本站其它相关文章！