不能直接用 std::queue + std::atomic 拼凑无锁队列，因为 std::queue 的 push/pop 包含多个非原子操作，仅原子化指针无法保证线性一致性，且忽略 ABA 问题和内存重排，易导致野指针或数据竞争。
为什么不能直接用 std::queue + std::atomic 拼凑无锁队列？
因为 std::queue 本身不是原子的，它的 push() 和 pop() 涉及多个非原子操作（如修改头尾指针、分配/释放节点、更新 size），哪怕把头尾指针声明为 std::atomic<node></node>，也无法保证整个操作的线性一致性。常见错误是只原子化指针读写，却忽略 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)，避免分支和除法
template<typename T, size_t N>
class spsc_queue {
static_assert((N & (N-1)) == 0, "N must be power of 2");
alignas(64) std::atomic<size_t> head_{0};
alignas(64) std::atomic<size_t> tail_{0};
T buffer_[N];
<p>public:
bool try<em>enqueue(const T& val) {
auto tail = tail</em>.load(std::memory_order_acquire);
auto next_tail = (tail + 1) & (N - 1);
if (next<em>tail == head</em>.load(std::memory_order<em>acquire)) return false;
buffer</em>[tail] = val;
tail_.store(next_tail, std::memory_order_release);
return true;
}</p><pre class='brush:php;toolbar:false;'>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++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 典型做法：用 64 位整数低 48 位存指针，高 16 位存版本号，每次 CAS 前递增版本
-
std::atomic<uint64_t></uint64_t>存储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 更实际。
