C++实现生产者消费者模型代码 _ mutex与condition

核心问题是唤醒丢失：生产者notify时消费者尚未wait，通知丢失；必须用wait谓词版本自动重检条件，且queue所有操作（含empty、size）都需加锁，notify_one/notify_all选择取决于单次推送数量。

c++实现生产者消费者模型代码 _ mutex与condition_variable【实战】

为什么用 `std::mutex` 和 `std::condition_variable` 实现生产者消费者容易卡死？

核心问题不是锁没加，而是唤醒丢失：消费者在 wait() 前被生产者发了 notify_one()，但此时消费者还没进入等待状态，通知就丢掉了。必须把「判断条件 + 等待」包进同一个原子操作里，也就是用 wait() 的谓词重载版本。

常见错误写法：

std::unique_lock<:mutex> lock(mtx);
while (queue.empty()) {
    cond.wait(lock); // ❌ 没有谓词，可能虚假唤醒后直接读空队列
}
// 取数据...
</:mutex>

正确做法是让 wait() 自动重检条件：

std::unique_lock<:mutex> lock(mtx);
cond.wait(lock, [&] { return !queue.empty(); }); // ✅ 虚假唤醒也会再检查
// 此时 queue 一定非空
</:mutex>

`std::queue` 本身线程不安全，所有访问都得加 `std::mutex`

哪怕只是 size() 或 empty()，也必须锁住——因为这些函数内部可能读多个成员变量，C++ 标准不保证其原子性。漏锁一处，就会触发未定义行为（比如读到半更新的 size）。

典型踩坑点：

在 wait() 谓词里直接写 queue.empty() 却没加锁 → 编译不过（queue 非 const 成员函数不能在 const lambda 里调）
用 if (queue.size() > 0) 判断后才加锁取数据 → 中间可能被其他线程清空
生产者 push 后只 notify，但没保证 push 本身已完成（即没锁保护）→ 数据可能写一半就被消费

所以所有对 queue 的读写操作，包括 empty()、front()、pop()、push()，都必须包裹在 std::unique_lock 作用域内。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

一个生产者多个消费者时，`notify_one()` 和 `notify_all()` 怎么选？

用 notify_one() 更高效，但前提是：每次 notify 都对应一个「真正能干活」的等待线程。如果多个消费者都在等，而你只 notify 一个，其余继续睡，没问题；但如果生产者一次 push 多个元素，却只 notify 一次，那其余消费者可能长期饥饿。

实操建议：

单次只 push 一个元素 → 用 notify_one()
批量 push（如从文件读一批数据）→ 推荐用 notify_all()，避免唤醒不足
若坚持用 notify_one() 批量场景，需确保每个消费者都能处理多条，且生产者 push 完立刻 notify 多次（不推荐，易错）

注意：notify_all() 不会唤醒已退出等待的线程，也不会导致重复消费——因为每个消费者醒来后都会重新检查 queue.empty()，只有第一个抢到锁且发现非空的才能取走数据。

别忘了 `std::condition_variable::wait()` 会自动释放和重获锁

这是最常被误解的一点：很多人以为要手动 unlock/lock，其实 wait() 内部做了两件事：先释放传入的 std::unique_lock，挂起线程；被唤醒后，再阻塞地重新获取该锁，才返回。所以以下写法是错的：

std::unique_lock<:mutex> lock(mtx);
cond.wait(lock);
lock.unlock(); // ❌ wait 返回时 lock 已持有，这里 unlock 会抛异常
// ...
lock.lock();   // ❌ 更错，重复 lock
</:mutex>

正确结构永远是：

std::unique_lock<:mutex> lock(mtx);
cond.wait(lock, [&]{ return !queue.empty(); });
// ✅ 此时 lock 有效，可安全访问 queue
auto item = queue.front();
queue.pop();
// lock 自动在作用域结束时释放
</:mutex>

这个自动管理是 std::unique_lock 和 std::condition_variable 配合设计的关键，强行干预反而破坏语义。