直接用 std::atomic 操作数组下标不等于无锁安全，因会触发 ABA 问题或读写撕裂；SPSC 可用简单原子操作但需严格内存序，MPMC 必须用 CAS、状态位和双 CAS 等机制。
为什么直接用 std::atomic 操作数组下标不等于无锁安全
很多人以为只要把 head 和 tail 声明为 std::atomic<int></int>，再配合 load()/store() 就能实现线程安全的循环队列——实际会触发 ABA 问题或读写撕裂。比如消费者读到旧的 tail 值后，生产者已循环两圈，导致越界读或漏读。
真正可靠的无锁循环队列必须满足：① 单生产者单消费者（SPSC）模型下可用简单原子操作；② 多生产者或多消费者（MPMC）必须引入内存序约束 + 额外状态位（如 std::atomic<bool></bool> 标记槽位是否就绪）；③ 所有指针/索引更新必须搭配 memory_order_acquire / memory_order_release。
- SPSC 场景下，
head只由消费者改，tail只由生产者改，可省略 CAS，但load()必须用memory_order_acquire，store()必须用memory_order_release - MPMC 场景下，
tail更新必须用compare_exchange_weak()，且失败后要重试，不能直接自增 - 队列容量必须是 2 的幂次（如 1024），才能用
index & (capacity - 1)替代取模，避免分支和除法开销
std::atomic_thread_fence() 在哪用、为什么不能乱用
在 SPSC 循环队列中，生产者写完数据后、更新 tail 前，需要插入 std::atomic_thread_fence(std::memory_order_release)；消费者读 tail 后、读数据前，需插入 std::atomic_thread_fence(std::memory_order_acquire)。这不是为了同步 tail 本身（它已是原子变量），而是确保编译器和 CPU 不会把数据写入重排到 tail 更新之后，或把数据读取重排到 tail 读取之前。
常见错误是把 fence 放错位置：比如放在 tail 更新之后才写数据，或者用 memory_order_seq_cst 当成万能解——这会强制全核同步，性能暴跌 3–5 倍。
立即学习“C++免费学习笔记（深入）”；
- SPSC 生产者流程：写数据 →
atomic_thread_fence(memory_order_release)→ 更新tail - SPSC 消费者流程：读
tail→atomic_thread_fence(memory_order_acquire)→ 读数据 - MPMC 中 fence 无法替代原子操作，必须配合 CAS 使用，否则仍存在竞态
如何避免“伪共享”让无锁队列变慢
即使逻辑无锁，如果 head 和 tail 落在同一缓存行（通常 64 字节），一个线程修改 head 会导致另一个线程的 tail 缓存失效，频繁触发总线广播——实测吞吐量可能下降 40% 以上。
解决方案不是靠注释或 padding 猜测，而是显式对齐 + 填充：把 head 和 tail 分别放在独立缓存行起始地址，并确保它们之间至少间隔 64 字节。
- 用
alignas(64)修饰head和tail所在结构体成员 - 或手动填充：
std::array<char> padding;</char>放在head和tail之间 - 用
perf stat -e cache-misses验证优化效果，而非仅看吞吐量数字
MPMC 场景下为何必须用“双 CAS”或“Ticket Lock + 原子索引”
纯原子索引的 MPMC 循环队列无法规避“丢失更新”：两个生产者同时读到相同 tail，各自计算出同一 slot，都写入后只有一方成功更新 tail，另一方数据被覆盖。标准解法是引入“预留槽位”机制——先 CAS 获取唯一 slot，再写数据，最后 CAS 提交 tail。
更实用的做法是采用 boost::lockfree::queue 底层策略：用一个 std::atomic<uint32_t></uint32_t> 记录全局 ticket，每个生产者先 fetch_add 获取唯一序号，再映射到物理 slot；消费者同样按序号消费。这种方式避免了反复 CAS 失败自旋，但要求 slot 数组足够大以容纳最大并发数。
- 不要试图用单个
compare_exchange_weak()同时更新tail和写数据——C++ 原子类型不支持复合操作 - slot 数据本身也得是原子类型（如
std::atomic<t></t>）或用std::atomic_thread_fence()保证可见性 - 当队列满时，MPMC 必须阻塞或返回 false，不能靠 while 循环空转，否则 CPU 占用飙高
真正的难点不在原子操作语法，而在内存序与缓存行为的耦合：一次看似正确的 store()，若缺少对应 load() 的 memory order，或落在错误缓存行，就足以让无锁退化为“假无锁”。调试时优先看 cache-misses 和 cycles，而不是盯着 std::atomic 的调用次数。
