MPSC无锁队列更适合任务派发，因其适配“多写单读”场景，避免锁竞争，吞吐提升3–5倍；但需正确使用release/acquire内存序、安全回收节点，并防范伪共享、NUMA延迟和队列溢出。
为什么 MPSC 无锁队列比 std::queue + mutex 更适合任务派发
因为任务派发天然就是“多线程写、单线程读”——网络线程收包后往队列塞任务，业务线程从队列取任务执行。用 std::queue 加 std::mutex，所有生产者会争抢同一把锁，锁竞争在 10+ 线程时就成性能瓶颈；而 MPSC 无锁队列让每个生产者只做一次 std::atomic<node>::exchange()</node>，没有系统调用、没有上下文切换、没有自旋等待，压测中常见吞吐提升 3–5 倍。
但注意：MPSC 不是万能的。如果你的消费者不止一个（比如多个业务线程轮询处理），就得换 MPMC 模型，否则会出现数据丢失或 ABA 问题。
选对内存序：release/acquire 是底线，别用 relaxed
MPSC 队列 push/pop 的正确性依赖于 happens-before 关系。典型错误是把 tail.store(new_node, std::memory_order_relaxed) 当成安全操作——它不阻止编译器或 CPU 把后续的 data 初始化重排到 store 之前，导致消费者看到未初始化的 data 字段。
必须这样写：
- push 中：用
std::memory_order_release存 tail，确保节点数据写入已完成 - pop 中：用
std::memory_order_acquire读 head，确保能看见该节点完整内容 - 绝对不要在关键指针更新上用
relaxed，哪怕 benchmark 看起来快——它会在某些 CPU（如 ARM）上直接崩溃
节点回收不是“delete 就完事”，得防 use-after-free
无锁队列里 pop 出来的节点不能立刻 delete，因为其他生产者可能还在用它的 next 指针。常见错误是写个简单引用计数，结果在高并发下原子增减本身又成了热点。
工程中稳妥的做法只有两种：
- 用
Hazard Pointers：消费者线程在访问节点前把自己的 hazard pointer 指向它，回收线程只回收没被任何 hazard pointer 指向的节点 - 用
Epoch-Based Reclamation (EBR)：按时间分代，当前 epoch 所有消费者都完成访问后，才批量回收上一代节点——开销低、适合单消费者场景 - 别自己手写 EBR，直接用
libcds或moodycamel::ConcurrentQueue的回收机制，它们已过大量压测
实际部署时最容易被忽略的三个点
第一，伪共享（False Sharing）：如果多个生产者线程频繁更新各自独立的队列头尾指针，但这些指针落在同一个缓存行（64 字节），会导致缓存行在核间反复无效化。解决方案是给 head、tail、guard 等字段手动填充 alignas(64)。
第二，NUMA 亲和性：若你的服务器是双路 CPU，确保生产者线程绑定在离网卡内存近的 NUMA 节点上，否则跨节点访存延迟会吃掉无锁带来的收益。
第三，队列深度监控：无锁队列不会阻塞，但若消费者长期跟不上，队列会无限增长，最终 OOM。必须在业务线程里定期检查 size()（需用原子操作实现），超阈值时触发降级（如丢弃低优先级任务）。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
