C++生产者消费者模式怎么用互斥锁和条件变量写-C++-PHP中文网

仅用std::mutex无法实现线程等待，必须配std::condition_variable：mutex保护临界区访问，condition_variable用于等待业务条件（如队列非空），避免忙等；notify需在锁内修改状态后调用，推荐notify_one，配合while循环防止虚假唤醒。

c++生产者消费者模式怎么用互斥锁和条件变量写

为什么不能只用 `std::mutex` 而必须配 `std::condition_variable`

只锁不等，消费者会疯狂轮询队列是否非空，CPU 白耗；生产者同理，可能往满队列硬塞。互斥锁管的是「临界区访问」，条件变量管的是「等某个业务条件成立」——比如 queue.empty() == false 或 queue.size() 。二者必须配合：锁保护共享状态，条件变量在锁内等待，并在被唤醒后重新检查条件（防止虚假唤醒）。

`std::condition_variable::wait` 必须传入 `std::unique_lock<:mutex></:mutex>`

不能传 std::lock_guard，也不能裸传 std::mutex。因为 wait 需要能临时释放锁（让其他线程进临界区改状态），并在唤醒时自动重新加锁。只有 std::unique_lock 支持移动和手动解锁/重锁。

常见错误写法：

std::lock_guard<:mutex> lock(mtx);  // ❌ 编译不过：wait 不接受 lock_guard
cv.wait(lock, [&]{ return !q.empty(); });</:mutex>

正确写法：

C++ Code Review Master

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

下载

std::unique_lock<:mutex> lock(mtx);
cv.wait(lock, [&]{ return !q.empty(); });  // ✅ lock 自动管理生命周期</:mutex>

lambda 条件里必须捕获引用（[&]），否则读到的是旧副本
不要在 wait 外再手动 lock.unlock()，会破坏原子性
唤醒后，lock 仍持有，可安全访问共享队列

消费者循环中必须用 `while` 而不是 `if` 检查条件

虚假唤醒（spurious wakeup）是 POSIX 和 C++ 标准允许的行为：线程可能没被 notify 就醒了。如果只用 if，醒来后直接取数据，极大概率 crash（队列实际还是空的）。

正确结构：

std::unique_lock<:mutex> lock(mtx);
while (q.empty()) {           // ✅ while，不是 if
    cv.wait(lock);
}
auto item = std::move(q.front());
q.pop();</:mutex>

生产者端同理：用 while (q.size() >= capacity) 等空间
所有对 q 的读写操作，必须在 lock 持有时进行
cv.notify_one() 放在修改完队列、且仍在锁内时最安全（避免唤醒后竞争）

多生产者/多消费者下 notify 的选择：`notify_one` 还是 `notify_all`？

多数场景用 notify_one 就够了：一个消费者醒来取走一个任务，其余继续睡。但要注意两个边界：

如果生产者在 push 后调用 notify_one，而此时没有消费者在 wait（比如刚启动），那这次通知就丢了 —— 所以条件检查永远在 wait 前做，靠 while 循环兜底
当有多个消费者且任务粒度很小时（如每条日志一个 notify），notify_all 可能引发惊群（thundering herd），大量线程争抢锁，反而降低吞吐。除非你明确需要「唤醒所有等待者一起干活」（比如 barrier 场景）
若用 notify_all，务必确保所有被唤醒线程都能处理当前状态（例如队列非空），否则部分线程又立刻 wait 回去，白耗调度开销

真正容易被忽略的是：notify 不必和 wait 在同一把锁下发生，但它必须在修改共享状态后、且该状态对等待者可见时调用 —— 也就是在同一个 unique_lock 作用域内完成修改 + notify 最稳妥。