直接用 std::mutex + std::condition_variable 比信号量更稳妥，因其跨平台一致、天然绑定缓冲区状态、避免信号量常见错误（如 EINTR 未处理、初始值设错），且需用 while 循环防虚假唤醒。
为什么直接用 std::mutex + std::condition_variable 比信号量更稳妥
Windows 和 Linux 对 sem_t 的实现细节不一致（比如 macOS 默认不支持命名信号量），而 C++11 起的 std::mutex 和 std::condition_variable 是标准库原生支持，跨平台无差异。更关键的是：条件变量天然绑定缓冲区状态（空/满），比手动维护两个信号量（empty_sem、full_sem）更难出错。
常见错误现象：sem_wait() 返回 -1 但没检查 errno == EINTR，导致生产者卡死；或信号量初始值设错（如 sem_init(&full_sem, 0, 1) 误写成 1 而非 0）。
- 缓冲区为空时，消费者必须等待 —— 这是
cv_empty.wait()的语义，不是靠sem_wait(&full_sem)模拟 - 用
std::queue时，push()和pop()都需在锁内完成，否则多线程下迭代器失效或 size() 返回脏值 - 避免虚假唤醒：
wait()必须配合 lambda 判断条件，不能只写cv.wait(lock)
std::condition_variable 的等待条件为什么必须用 while 而不是 if
因为 notify_one() 只是“建议系统唤醒一个等待线程”，不保证立刻执行；多个线程可能同时被唤醒（尤其 notify_all()），或因系统调度延迟导致条件已再次变化。直接用 if 会跳过二次检查，从空队列取数据触发 std::queue::front() 崩溃。
实操建议：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 消费者循环中必须写
while (q.empty()) { cv_empty.wait(lock); }，不能是if - 生产者同理：
while (q.size() >= capacity) { cv_full.wait(lock); } - 哪怕只用一个条件变量（如只监控非空），也要 while，这是 POSIX 和 C++ 标准明确要求的
缓冲区 size() 和 capacity 怎么防溢出和假死
std::queue 的 size() 在某些 STL 实现里不是 O(1)，且多线程下不可信 —— 它不加锁，返回的可能是中间态。真正可靠的容量控制必须依赖显式计数器或环形缓冲区索引差值。
推荐做法：
- 用
std::vector<T>+ 两个原子整数head、tail实现环形缓冲区，避免动态内存分配开销 - 若坚持用
std::queue，额外维护std::atomic_size_t current_size{0}，每次 push/pop 后原子增减 - capacity 设为 2 的幂（如 1024），方便位运算取模：
tail = (tail + 1) & (capacity - 1)，比% capacity快且无分支
为什么不用 std::shared_mutex 或读写锁
生产者消费者不是“多读少写”场景：每次 push/pop 都是独占操作，不存在并发读。用 std::shared_mutex 反而增加 acquire/release 开销，且 C++17 前不支持，兼容性差。
真实瓶颈通常在：
- 缓冲区太小 → 频繁等待 → 改用无锁环形缓冲区（如
boost::lockfree::queue） - 生产/消费逻辑本身慢 → 锁持有时间长 → 把耗时操作移出临界区（例如先生成数据，再加锁入队）
- 单个缓冲区成为争用点 → 拆成多个分片队列，按哈希分流
最易被忽略的一点：所有共享对象（包括 std::queue、计数器、条件变量）必须定义在生产者/消费者线程之外，且生命周期长于线程——局部变量传引用进 std::thread 是悬垂引用，崩溃只是时间问题。
