最简可行方案是std::queue配合std::mutex和两个std::condition_variable（not_empty和not_full）。该方案稳定、易调试、兼容C++11+，仅在实测吞吐达百万级/秒或需wait-free语义时才考虑无锁替代。
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() 后，可能唤醒的是另一个正在等“有空位”的生产者（而非消费者），结果它发现队列还是满的，又得回去等；同理，消费者也可能被误唤醒去取空队列。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 两个 condition_variable 是对“等待原因”做显式建模：一个是“我因为空等数据”，一个是“我因为满等空间”
-
not_empty.wait()只该由生产者 notify，not_full.wait()只该由消费者 notify —— 这种职责绑定能避免虚假唤醒扩散 - 如果硬要减变量，可改用带状态的单一 cv（例如用
std::atomic<bool></bool>标记“是否有数据”或“是否有空位”），但代码可读性和调试难度陡增，不推荐
多线程并发 push/pop 时最容易踩的坑
现象：程序偶尔崩溃、数据丢失、queue.size() 返回负值或极大值、消费者永远阻塞 —— 这些几乎全是未正确加锁导致的未定义行为（UB）。
常见错误模式：
-
if (queue.empty()) { lock_guard lock(mtx); cv.wait(...); }—— 错！empty()在锁外执行，中间窗口期可能被其他线程修改 - 在
wait()的谓词 lambda 中捕获局部变量（如[queue]），而不是引用（[&]）—— 编译失败或运行时访问野指针 - 在锁内调用耗时操作，比如
std::this_thread::sleep_for()或日志打印 —— 卡死整个队列，所有线程排队等锁 - 忘记在
pop()后调用not_full.notify_one()—— 生产者永远等不到“有空位”，队列卡死在满状态
什么时候该换 moodycamel::ConcurrentQueue 或 Boost lockfree
当且仅当你观察到以下任一情况时，才考虑替换为无锁队列：
- 用
perf或 VTune 测出std::mutex::lock占用 CPU 时间 >15%，且队列操作是性能瓶颈热点 - 单个队列每秒 push/pop 超过 50 万次，且线程数 ≥8，此时
std::mutex的争用明显抬高延迟毛刺 - 你明确需要 wait-free 语义（例如硬实时系统中不能容忍锁阻塞）
注意：moodycamel 和 Boost lockfree 都要求元素类型满足 trivially copyable，且不提供阻塞 pop；你要自己轮询 + sleep，或者封装成类似 wait_dequeue() 的逻辑 —— 这部分工作量常被低估。
真正难的从来不是“怎么换队列”，而是“怎么验证新队列在边界条件下（如内存压力、信号中断、线程突然终止）仍不泄漏、不卡死”。标准 mutex+cv 方案的健壮性，是经过二十多年真实系统锤炼出来的。
