C++生产者消费者模型怎么设计支持多生产多消费-C++-PHP中文网

最简可行方案是std::queue配合std::mutex和两个std::condition_variable（not_empty和not_full）。该方案稳定、易调试、兼容c++11+，仅在实测吞吐达百万级/秒或需wait-free语义时才考虑无锁替代。

c++生产者消费者模型怎么设计支持多生产多消费

std::queue + std::mutex + std::condition_variable 是最简可行方案

别一上来就琢磨无锁队列或 C++20 std::counting_semaphore。多生产多消费场景下，std::queue 配合单个 std::mutex 和两个 std::condition_variable（not_empty 和 not_full）已足够稳定、易调试、兼容所有 C++11+ 编译器。

关键不是“能不能”，而是“要不要引入额外复杂度”——除非你实测吞吐卡在锁竞争上（比如每秒百万级 push/pop），否则用标准容器加原生同步原语是最省心的选择。

not_empty 专用于消费者等待：消费者线程调用 wait(lock, [&]{ return !queue.empty(); })，唤醒后必须在锁内取数据
not_full 专用于生产者等待：生产者线程在 push() 前检查 queue.size() ，同样在锁内判断+插入
所有访问都必须进锁：empty()、size()、front()、pop()、push() —— std::queue 没有线程安全保证，哪怕只读也不行
别用 notify_all()：多个消费者同时被唤醒，只有一个能取走数据，其余立刻重入等待，徒增上下文切换。一律用 notify_one()

为什么不能只用一个 condition_variable

用单个 std::condition_variable（比如只留 cv）看似简洁，但会破坏语义分离，导致唤醒逻辑混乱。

典型问题：生产者调用 cv.notify_one() 后，可能唤醒的是另一个正在等“有空位”的生产者（而非消费者），结果它发现队列还是满的，又得回去等；同理，消费者也可能被误唤醒去取空队列。

两个 condition_variable 是对“等待原因”做显式建模：一个是“我因为空等数据”，一个是“我因为满等空间”
not_empty.wait() 只该由生产者 notify，not_full.wait() 只该由消费者 notify —— 这种职责绑定能避免虚假唤醒扩散
如果硬要减变量，可改用带状态的单一 cv（例如用 std::atomic<bool></bool> 标记“是否有数据”或“是否有空位”），但代码可读性和调试难度陡增，不推荐

多线程并发 push/pop 时最容易踩的坑

现象：程序偶尔崩溃、数据丢失、queue.size() 返回负值或极大值、消费者永远阻塞 —— 这些几乎全是未正确加锁导致的未定义行为（UB）。

C++ Code Review Master

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

下载

常见错误模式：

if (queue.empty()) { lock_guard lock(mtx); cv.wait(...); } —— 错！empty() 在锁外执行，中间窗口期可能被其他线程修改
在 wait() 的谓词 lambda 中捕获局部变量（如 [queue]），而不是引用（[&]）—— 编译失败或运行时访问野指针
在锁内调用耗时操作，比如 std::this_thread::sleep_for() 或日志打印 —— 卡死整个队列，所有线程排队等锁
忘记在 pop() 后调用 not_full.notify_one() —— 生产者永远等不到“有空位”，队列卡死在满状态