c++如何实现生产者消费者模型_c++ 互斥锁与条件变量协同工作【案例】

必须用 std::condition_variable 配合 std::mutex 实现生产者消费者模型，因互斥锁无法解决空/满队列时的线程等待问题；wait() 必须在 unique_lock 持有锁时调用，且需用 while 循环或带谓词的重载检查条件，避免虚假唤醒。

用 std::mutex 和 std::condition_variable 实现生产者消费者模型，是 C++ 多线程中最典型、也最容易出错的协同场景。核心在于：锁只保护临界区，而条件变量负责“等某个状态成立”，二者必须配合使用，且 wait() 调用前必须已持有锁。

为什么不能只用互斥锁？

互斥锁能阻止多个线程同时访问共享队列，但无法解决“队列空时消费者该干什么”或“队列满时生产者该干什么”的问题。轮询（busy-wait）浪费 CPU；单纯加锁后 return 又会导致线程退出，无法持续工作。这时候必须靠 std::condition_variable 挂起线程，等条件满足再唤醒。

std::condition_variable::wait() 的正确调用姿势

这是最常踩坑的地方：wait() 必须在已锁定的 std::unique_lock<:mutex> 上调用，且内部会自动释放锁并挂起线程；被唤醒后，它会重新获取锁，再返回 —— 但此时条件未必仍成立（可能被其他线程抢走资源），所以必须用 while 循环判断，不能用 if。

• 错误写法：if (queue.empty()) cv.wait(lock); → 唤醒后不检查，可能读空队列
• 正确写法：while (queue.empty()) cv.wait(lock);
• wait() 的第二个参数可以是 lambda，等价于 while + lambda 调用，更简洁：cv.wait(lock, [&]{ return !queue.empty(); });

生产者与消费者的完整协作逻辑

假设共享一个 std::queue，容量上限为 10：

立即学习“C++免费学习笔记（深入）”；

Whimsical

Whimsical推出的AI思维导图工具

下载

#include 
#include 
#include 
#include 
#include 
std::queue q;
std::mutex mtx;
std::condition_variable cv_not_full, cv_not_empty;
const int MAX_SIZE = 10;
void producer(int id) {
for (int i = 0; i < 5; ++i) {
std::unique_lock lock(mtx);
cv_not_full.wait(lock, [&]{ return q.size() < MAX_SIZE; });
q.push(i + id  10);
std::cout << "P" << id << " pushed " << (i + id  10) << ", size=" << q.size() << "\n";
lock.unlock(); // 手动解锁，避免阻塞消费者
cv_not_empty.notify_one(); // 通知至少一个消费者
}
}
void consumer(int id) {
for (int i = 0; i < 5; ++i) {
std::unique_lock lock(mtx);
cv_not_empty.wait(lock, [&]{ return !q.empty(); });
int val = q.front();
q.pop();
std::cout << "C" << id << " popped " << val << ", size=" << q.size() << "\n";
lock.unlock();
cv_not_full.notify_one(); // 通知至少一个生产者
}
}

注意两点：一是 notify_one() 在锁外调用更安全（避免唤醒后立即竞争锁）；二是两个条件变量分别对应“非满”和“非空”，不能共用一个 —— 否则 notify_all() 会同时唤醒所有生产者和消费者，造成无谓竞争。

容易忽略的边界与性能点

实际部署时这几个细节常被跳过：

• 共享队列未加 std::atomic 或锁保护，直接裸读写 → 数据竞争，UB
• 忘记在 wait() 的 lambda 中捕获引用（如 [&]），导致读到的是旧值或编译失败
• 用 std::lock_guard 替代 std::unique_lock → wait() 编译不过，因为后者需要支持中途释放/重获锁
• 生产者 push 后只调用 notify_one()，但如果有多个消费者等待，可能唤醒的是刚处理完的线程，而其他线程还在等 —— 此时用 notify_all() 更稳妥（代价是唤醒开销略高）

真正难的不是写出来，而是想清楚「谁在等什么条件」「谁来通知」「通知之后是否真能满足」—— 这三问没理清，wait() 就会永远挂住，或者频繁虚假唤醒。