std::queue + mutex 不够用，因其无容量限制，无法实现背压；需用有界环形队列（如 std::array + 原子索引 + mutex），入队前检查满状态并阻塞，确保生产者主动暂停。
为什么 std::queue + mutex 不够用？
因为 std::queue 本身不带容量限制，生产者拼命 push，消费者稍一卡顿，队列就无限膨胀，最终吃光内存。背压的核心不是“等消费者来取”，而是“生产者主动感知队列已满并暂停”。这要求队列有明确的容量上限，且阻塞逻辑必须绑定在入队操作上。
常见错误现象：std::queue 配 std::mutex + std::condition_variable，但只对“空”做等待（wait for not empty），完全忽略“满”的判断——这就没有背压，只有单向流控。
- 必须用有界容器，比如
std::array+ 环形缓冲区，或封装了 size/capacity 检查的队列类 - 入队前必须检查剩余容量，满则
wait；出队后需通知生产者可继续入队 - 避免用
std::queue的底层容器（如std::deque）直接暴露，它不提供capacity()
如何用 std::array 实现线程安全的有界环形队列？
比 boost::lockfree::spsc_queue 更可控，也比自己手写锁+条件变量更少出错。关键点在于：两个原子索引（head_ 和 tail_）控制读写位置，配合一个 std::mutex 保护容量判断和内存访问，而不是保护整个 push/pop。
使用场景：中低吞吐、需要确定性内存占用（如嵌入式、音视频帧缓冲）、或不想引入 lockfree 复杂性的服务模块。
立即学习“C++免费学习笔记（深入）”；
- 定义大小为
N的std::array<T, N>，N必须是 2 的幂（方便位运算取模） -
push()先算(tail_ + 1) & (N - 1)，若等于head_则队列满，调用cv_.wait() -
pop()成功后立刻cv_.notify_one()，让等待中的生产者有机会入队 - 不要把
std::mutex锁粒度设成“整个函数”，只锁住索引更新和元素拷贝这两步
std::condition_variable::wait() 怎么避免虚假唤醒导致背压失效？
虚假唤醒本身不会破坏背压，但如果你的等待条件写成 cv_.wait(lock, [&]{ return !is_full(); }); 却没确保 is_full() 是原子或受同一锁保护，就可能读到过期状态——结果是生产者以为有空间，实际已经满了。
典型错误：在 wait 的 lambda 里只读 tail_ 和 head_，但这两个变量没声明为 std::atomic，也没被互斥锁保护，编译器或 CPU 可能重排或缓存旧值。
- 要么把
head_/tail_声明为std::atomic<size_t>，并在wait条件中用.load()读取 - 要么放弃原子变量，统一用
std::mutex包裹所有对容量和索引的访问，包括wait的谓词 - 永远不要在
wait谓词外单独判断“是否满”，否则竞争窗口会导致 double-push
要不要用 wait_for + 超时来防死锁？
要，但不是为了“防死锁”，而是防“某一方永久离线”。比如消费者崩溃，生产者一直 wait 就卡死。真实系统里，你得知道“等多久还不行，就该记录告警或降级丢弃”。
性能影响很小：一次 wait_for 比 wait 多一次系统调用开销，但在背压场景下本就不该高频触发；兼容性没问题，C++11 起就支持。
- 超时时间不能拍脑袋定，建议设为业务可容忍的最大延迟，比如音视频是 200ms，日志采集可以是 5s
- 超时返回后别直接
throw或exit，先尝试try_pop()清一点缓冲，再决定丢弃还是重试 - 注意
wait_for返回false时，锁仍持有，记得unlock()或用 RAII
最易被忽略的是：背压生效的前提，是生产者真的会响应“满”的信号。如果生产者在异步回调里调用 push，又没处理阻塞或超时，那整个机制就形同虚设——背压不是库的事，是调用方的责任。
