为什么 std::queue 不能直接用于多生产者场景
因为 std::queue 本身不保证线程安全，所有操作（push、pop、size）都非原子。多个线程同时调用 push 会破坏内部容器（如 std::deque）的指针一致性，大概率触发段错误或数据错乱。即使加锁封装，也违背“无锁”前提——锁本身就是性能瓶颈和调度不确定性来源。
常见错误现象：double free、use-after-free、segfault in std::deque::_M_push_back_aux；使用场景是高频日志写入、网络包收发等低延迟路径；关键不是“能不能跑”，而是“出不出错”和“延迟抖动是否可控”。
boost::lockfree::queue 的坑：MPSC 模式必须显式启用
boost::lockfree::queue 默认是单生产者单消费者（SPSC），直接在多线程中调用多个 push 会导致未定义行为——它不会报错，但数据会静默丢失或内存越界。必须用模板参数强制启用 MPSC 模式：
boost::lockfree::queue<int, boost::lockfree::capacity<1024>> q;
这不是语法糖，而是底层内存布局和 CAS 操作序列的根本差异。漏掉 boost::lockfree::fixed_sized<true></true> 或容量约束，编译可能通过，但运行时在某些平台（如 ARM64）会因对齐问题崩溃。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 永远显式指定
boost::lockfree::capacity<n></n>，避免动态分配路径 - 确认 Boost 版本 ≥ 1.58，旧版 MPSC 实现有 ABA 风险
- 不要混用
push和bounded_push：后者失败返回false，前者会死循环重试
手写 MPSC 无锁队列的核心约束：只允许一个消费者调用 pop
MPSC 的“无锁”本质是把竞争点从两端压到一端：多个生产者用 CAS 竞争写入尾指针，消费者独占读取头指针。这意味着 pop 函数内不能有任何共享状态更新（比如引用计数、回调通知），否则就引入新竞争点。
容易踩的坑：
- 在
pop里调用虚函数或锁保护的日志函数——立刻退化成有锁路径 - 误以为“无锁=无同步”，忽略内存序：
std::memory_order_relaxed用于内部计数，但head/tail更新必须用std::memory_order_acquire/std::memory_order_release - 用
std::atomic<node></node>但没对齐节点内存：x86 允许非对齐访问，ARM 会 SIGBUS
最小可行示例的关键行：
Node* expected = head_.load(std::memory_order_acquire);和
head_.compare_exchange_weak(expected, expected->next, std::memory_order_acquire);
性能陷阱：缓存行伪共享（false sharing）比锁更隐蔽
生产者频繁更新的 tail_ 和消费者频繁更新的 head_ 如果落在同一缓存行（通常 64 字节），会导致 CPU 核心反复无效化对方的缓存副本，吞吐量骤降 3–5 倍。这不是代码逻辑错误，而是在 perf report 里看到大量 cache-misses 却找不到锁竞争。
实操建议：
- 用
alignas(64)分别对齐head_、tail_、size_counter等原子变量 - 避免在队列结构体内塞入无关字段（比如调试用的
std::atomic<size_t> debug_count</size_t>） - 在 NUMA 系统上，确保生产者线程绑定到同一 socket，减少跨片访问延迟
真正难的不是写出能编译的无锁代码，而是让它的性能曲线在 20+ 生产者下依然平滑——这取决于你是否把内存布局、编译器屏障、CPU cache 行为当成接口契约的一部分。
