不能直接用std::atomic自增取模更新读写索引，因回绕时存在ABA问题和操作非原子性；须用fetch_add获取旧值后手动位运算计算新位置，并配对memory_order_acquire/release，容量须为2的幂以支持& (capacity-1)快速取模。
为什么不能直接用 std::atomic<size_t></size_t> 做读写索引的无锁更新
因为环形缓冲区的读写索引存在“回绕”（wrap-around），单纯原子自增后取模会引发 ABA 问题和边界竞争：比如写端刚把 write_index 从 N-1 更新为 0，读端可能在未同步到新值时误判为缓冲区为空。更关键的是，operator++ 和取模是两个独立原子操作，中间无法保证逻辑原子性。
实操建议：
- 用
fetch_add(1, std::memory_order_acquire)获取旧值，再手动计算新位置：new_pos = old_val % capacity，避免两次原子操作间被干扰 - 读写索引必须用
std::memory_order_acquire（读）和std::memory_order_release（写）配对，防止编译器/CPU 重排导致数据未写入就更新索引 - 容量必须是 2 的幂（如 1024、4096），这样可用位运算
& (capacity - 1)替代取模，既快又避免分支
如何安全判断缓冲区满/空而不依赖额外计数器
引入计数器会增加一次原子读写，破坏单生产者单消费者（SPSC）场景下的真正无锁性。标准做法是「预留一个空槽」：当 (write_index + 1) & mask == read_index 表示满；当 write_index == read_index 表示空。这要求缓冲区实际可用长度为 capacity - 1。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 用
write_index == read_index判断满 → 永远无法写入最后一个元素 - 没对齐容量，用
(write_index + 1) % capacity == read_index→ 取模慢且可能因编译优化出错 - 在多生产者场景下仍套用 SPSC 判定逻辑 → 出现写覆盖或读脏数据
性能影响：SPSC 下满/空判定是纯寄存器运算，零延迟；加计数器则每次写都要 fetch_add 再比较，吞吐下降 15%~20%（实测 clang 15 + x86-64）
std::atomic_thread_fence 在跨线程可见性中的真实作用点
很多人以为只要索引用了 atomic，数据数组就自动同步了。其实不是：写端写完 buffer[write_pos] 后，必须用 std::atomic_thread_fence(std::memory_order_release) 保证该写入不被重排到索引更新之后；读端读 buffer[read_pos] 前，要用 std::atomic_thread_fence(std::memory_order_acquire) 保证能看见之前所有写入。
使用场景：
- 仅在 SPSC 场景下可省略 fence（靠索引原子操作隐式同步），但代码可读性和移植性差
- MPSC 或 SPMC 必须显式 fence，否则可能读到未初始化的内存（尤其在 ARM/AArch64 上）
- Clang/GCC 对
memory_order_relaxed索引 + fence 的组合优化很激进，漏掉 fence 会导致偶发崩溃，难以复现
为什么推荐用 std::array<t n></t> 而非 std::vector<t></t> 存储缓冲区数据
std::vector 的堆分配引入额外指针间接访问，且其 data() 返回的地址在移动构造/赋值后可能变化，而无锁结构要求缓冲区生命周期严格固定。更重要的是，std::array 支持 trivially copyable 类型的批量原子操作（如 memcpy），便于实现批量读写。
参数差异：
- 模板参数
N必须是编译期常量，强制容量确定 —— 这反而是优势，避免运行时扩容破坏无锁假设 - 若
T非 trivially destructible（如含虚函数或自定义析构），需额外管理对象生命周期，此时应改用 placement new + 显式调用 destructor - 不要用
std::unique_ptr<t></t>替代 —— 智能指针内部有原子引用计数，完全违背无锁初衷
容易被忽略的地方是：即使你只做 SPSC，只要 T 是 non-trivial 类型（比如 std::string），就必须在写入前用 placement new 构造、读出后显式析构，否则会泄漏或重复析构。这个细节在多数开源 ring buffer 实现里都被简化掉了。
