SPSC场景下仅需std::atomic+数组即可高效实现，因生产者与消费者各自独占write_index和read_index，无竞争；配合memory_order_acquire/release、2的幂容量、缓存行对齐及快照式边界检查，即可达成近硬件极限吞吐。
为什么 SPSC 场景下 std::atomic + 数组就够了
多生产者多消费者（MPMC）需要复杂内存序和 CAS 重试逻辑，但单生产单消费（SPSC）天然避免了竞争：生产者只改 write_index，消费者只改 read_index，两者互不干扰。只要用 std::atomic 保证单次读写原子性，并配合适当的内存序（memory_order_acquire/memory_order_release），就能绕过锁、避免缓存行伪共享、获得接近硬件极限的吞吐。
关键点不是“无锁”，而是“无竞争”——这使得实现可以极度轻量：
-
write_index和read_index必须是std::atomic<size_t></size_t>，不能是普通size_t - 缓冲区大小必须是 2 的幂（如 1024、4096），才能用位运算快速取模：
index & (capacity - 1) - 不需要
std::atomic_thread_fence——load(acquire)和store(release)已隐含所需同步语义
如何避免 ABA 和写指针超前读指针？
SPSC 不会遇到典型 ABA 问题（因为只有一个写线程修改 write_index），但容易踩另一个坑：生产者在未检查容量时就自增 write_index，导致它“跑太远”，超过消费者能处理的范围。正确做法是先算出当前可写长度，再决定是否推进指针。
典型错误写法：
立即学习“C++免费学习笔记（深入）”；
size_t w = write_index.load(); size_t r = read_index.load(); if ((w - r) == capacity) return false; // 满 buffer[w & mask] = item; write_index.store(w + 1); // ❌ 危险：w 可能已失效
正确做法是用一次 load 获取快照，并基于该快照计算：
size_t w = write_index.load(std::memory_order_acquire); size_t r = read_index.load(std::memory_order_acquire); size_t avail = r - w + capacity; // 无符号减法自动折返 if (avail == 0) return false; buffer[w & mask] = item; write_index.store(w + 1, std::memory_order_release); // ✅ 基于原始 w 推进
注意：这里利用了无符号整数溢出的定义行为（ISO C++ 标准保证），r - w + capacity 在满时为 0，空时为 capacity。
为什么不用 std::atomic::fetch_add 直接递增？
看起来 write_index.fetch_add(1) 更简洁，但它隐含一个读-改-写周期，且返回的是旧值。而 SPSC 中我们真正需要的是“在确认有空间的前提下，安全地推进指针”。如果直接 fetch_add，就失去了对容量边界的原子判断能力——你无法在一个原子操作里同时检查剩余空间并递增。
所以标准做法是两步（load → 判断 → store），但这两步对各自指针是独立的，不构成竞争。性能上几乎无损：现代 CPU 的 load 和 store 都是单周期指令，且编译器通常能优化掉冗余内存访问。
- 不要用
fetch_add替代显式 load+store 判断逻辑 - 消费者端同理：先 load 读指针和写指针，算出可读数量，再取数据，最后 store 新读指针
- 所有 store 必须用
memory_order_release，所有 load 必须用memory_order_acquire，否则编译器/CPU 可能重排访存顺序
实际使用中最容易被忽略的边界：内存对齐与缓存行隔离
即使逻辑完全正确，若 read_index 和 write_index 落在同一个缓存行（通常是 64 字节），生产者和消费者的 store/load 会反复使对方的缓存行失效（false sharing），性能暴跌到接近有锁水平。
解决方法是强制将两个原子变量隔开：
alignas(64) std::atomic<size_t> read_index{0};
// 至少 64 字节填充（或直接用 alignas(64) 分开）
alignas(64) std::atomic<size_t> write_index{0};更稳妥的做法是把它们包进独立结构体，并加 padding：
struct alignas(64) ReaderSlot {
std::atomic<size_t> read_index{0};
char _pad[64 - sizeof(std::atomic<size_t>)];
};
struct alignas(64) WriterSlot {
std::atomic<size_t> write_index{0};
char _pad[64 - sizeof(std::atomic<size_t>)];
};没有对齐，再好的无锁逻辑也白搭——这是实测中性能差距常达 3–5 倍的关键点。
