不能直接用 std::queue + std::atomic 拼凑无锁队列，因为 std::queue 的 push/pop 包含多个非原子操作，仅原子化指针无法保证线性一致性，且忽略 ABA 问题和内存重排，易导致野指针或数据竞争。
为什么不能直接用 std::queue + std::atomic 拼凑无锁队列？
因为 std::queue 本身不是原子的，它的 push() 和 pop() 涉及多个非原子操作（如修改头尾指针、分配/释放节点、更新 size），哪怕把头尾指针声明为 std::atomic，也无法保证整个操作的线性一致性。常见错误是只原子化指针读写，却忽略 ABA 问题和内存重排——比如消费者读到旧的 tail，以为有新节点，实际该节点已被回收并复用，导致解引用野指针。
用 Michael-Scott 算法实现单生产者单消费者（SPSC）无锁队列的关键点
SPSC 是唯一能用纯 std::atomic + 顺序一致内存序（std::memory_order_seq_cst）安全实现的场景，无需复杂 hazard pointer 或 epoch-based reclamation。核心是两个原子指针：head（消费者端）、tail（生产者端），以及环形缓冲区（避免动态分配）。
-
enqueue()只由一个线程调用：先读tail，计算下一个索引，用compare_exchange_weak尝试推进tail；成功后才写入元素 -
dequeue()同理，只由一个线程调用：读head，计算索引，compare_exchange_weak推进head，再读出元素 - 必须用
std::memory_order_acquire读指针、std::memory_order_release写指针，或统一用seq_cst（SPSC 下性能可接受） - 缓冲区大小必须是 2 的幂，用位运算取模：
index & (capacity - 1)，避免分支和除法
templateclass spsc_queue { static_assert((N & (N-1)) == 0, "N must be power of 2"); alignas(64) std::atomic head_{0}; alignas(64) std::atomic tail_{0}; T buffer_[N]; public: bool tryenqueue(const T& val) { auto tail = tail.load(std::memory_order_acquire); auto next_tail = (tail + 1) & (N - 1); if (nexttail == head.load(std::memory_orderacquire)) return false; buffer[tail] = val; tail_.store(next_tail, std::memory_order_release); return true; }
bool try_dequeue(T& val) { auto head = head_.load(std::memory_order_acquire); if (head == tail_.load(std::memory_order_acquire)) return false; val = std::move(buffer_[head]); head_.store((head + 1) & (N - 1), std::memory_order_release); return true; }};
MPMC 场景下为什么必须处理 ABA 问题？
多生产者多消费者时，仅靠
compare_exchange_weak无法防止 ABA：线程 A 读到指针 P，被抢占；线程 B 把 P 指向的节点弹出、释放、又新建一个新节点恰好复用同一地址 P；线程 A 恢复后仍认为 P 有效，compare_exchange成功但语义错误。解决方案不是禁用优化，而是给指针附加版本号（tagged pointer）。立即学习“C++免费学习笔记（深入）”；
- 典型做法：用 64 位整数低 48 位存指针，高 16 位存版本号，每次 CAS 前递增版本
std::atomic存储head和tail，CAS 时同时比对指针+版本- 注意：x86_64 支持
cmpxchg16b，但需编译器支持-mcx16；否则退回到基于 hazard pointer 的方案（如 Folly::MPMCQueue）- 不要手动用
reinterpret_cast强转指针到整数再拼接——未定义行为，应使用std::bit_cast（C++20）或联合体（union）安全地拆解内存序选错会导致什么具体现象？
在 SPSC 队列中若把
tail_.store改成std::memory_order_relaxed，可能造成消费者看到更新后的tail却读到未初始化的buffer_[old_tail]；因为编译器或 CPU 重排了写缓冲区数据和写tail的顺序。同样，head_.load若用relaxed，可能读到过期的head值，导致重复消费或跳过元素。
- 正确组合：写指针用
release，读指针用acquire，构成同步关系（synchronizes-with）seq_cst更安全但有性能代价，在 x86 上多数seq_cststore 会插入mfence，而releasestore 通常只是普通 store- ARM/AArch64 上差异更大：
acquire/release对应ldar/stlr指令，seq_cst需额外 barrier无锁队列真正难的不是写几个
atomic操作，而是验证边界条件：满/空状态判断是否严格互斥、内存生命周期是否可控、不同架构下重排是否被正确约束。MPMC 场景下，几乎没人从零手写可靠实现——直接用boost::lockfree::queue或moodycamel::ConcurrentQueue更实际。
