不能用 std::queue 做环形缓冲区，因其底层 std::deque 内存不连续、无原子读写指针接口，无法满足固定大小、连续内存、独立指针推进和 wrap-around 等核心要求。
为什么不用 std::queue 做环形缓冲区
因为 std::queue 底层默认用 std::deque，内存不连续，没法靠指针加减实现真正的“环形”；而且它没提供读写位置的原子访问接口，无法支撑无锁逻辑。环形缓冲区核心诉求是：固定大小、内存连续、读写指针可独立推进、支持 wrap-around（越界回绕）。所以得自己管内存和指针算术。
常见错误现象：std::queue::size() 在多线程里不可靠；用 std::vector 动态扩容会破坏地址稳定性；手动 new char[N] 但没对齐，导致原子操作失败（尤其在 ARM 或 x86-64 的 std::atomic<uintptr_t></uintptr_t> 上）。
- 必须用
alignas(64)对齐缓冲区（主流 CPU 缓存行宽度） - 容量必须是 2 的幂（方便用位运算代替取模，避免分支和除法）
- 读写指针类型建议用
std::atomic<size_t></size_t>，别用int或裸指针
怎么写一个基础的单生产者单消费者（SPSC）环形缓冲区
SPSC 是唯一能完全无锁（lock-free）且无需内存屏障的场景——因为读写各只有一方，只需保证指针更新的原子性 + 数据写入的顺序可见性。关键不是“锁不锁”，而是“谁能看到谁的写”。
典型使用场景：日志采集线程往缓冲区塞数据，主线程定时刷盘；传感器采样中断服务程序写，用户态线程读。
立即学习“C++免费学习笔记（深入）”；
- 缓冲区大小设为
N（2 的幂），则有效容量是N - 1（留 1 空位区分满/空） - 写指针推进后，先写数据，再更新指针（否则读者可能读到未初始化内存）
- 读指针推进前，先读数据，再更新指针（否则写者可能覆盖未读数据）
- 用
(index & (N - 1))替代index % N，前提是N是 2 的幂
示例片段（简化版）：
class SPSCRingBuffer {
alignas(64) char buf_[1024];
std::atomic<size_t> write_idx_{0};
std::atomic<size_t> read_idx_{0};
public:
bool try_push(const char* data, size_t len) {
size_t w = write_idx_.load(std::memory_order_relaxed);
size_t r = read_idx_.load(std::memory_order_acquire);
if ((w - r) >= 1023) return false; // 满
memcpy(buf_ + (w & 1023), data, len);
write_idx_.store(w + 1, std::memory_order_release);
return true;
}
};
多生产者或多消费者时，为什么不能直接加锁
加锁本身不违反“无锁队列基础结构”的定位，但一旦加锁，就失去了 lock-free 的核心优势：任意线程崩溃不会阻塞其他线程。更现实的问题是性能瓶颈——比如多个采集线程争抢同一个 std::mutex，吞吐量卡死在几十万 ops/s，而无锁 SPSC 轻松破千万。
真正难的是 MPSC（多生产单消费）或 MPMC（多对多）：需要解决 ABA 问题、指针更新竞争、内存重排干扰。这时候不能只靠 std::atomic::compare_exchange_weak，还得配合适当的 memory order 和 padding 防伪共享（false sharing）。
- MPSC 至少要两个写指针字段：
write_idx（全局）和local_write_idx（每个生产者私有），避免写指针成为热点 - 所有原子操作尽量用
std::memory_order_acquire/release，别图省事全用relaxed - 读写指针变量之间至少隔 64 字节（用
alignas(64)或填充数组），否则不同线程改不同指针也会因缓存行冲突拖慢
容易被忽略的边界：字节序、对齐、调试验证
环形缓冲区出问题，90% 不是逻辑错，而是底层细节失控。比如在嵌入式平台用 uint8_t* 直接 cast 成 int32_t* 读写，结果因未对齐触发硬件异常；或者调试时用 gdb 打印 read_idx_ 值，却发现它“卡住不动”，其实是优化让变量被寄存器缓存，没刷新到内存。
- 所有跨线程访问的变量，必须声明为
std::atomic，哪怕只是size_t—— 普通变量的读写在 C++ 标准里不保证原子性 - 缓冲区起始地址必须满足目标类型对齐要求（例如存
double就要 8 字节对齐），否则memcpy可能变慢，甚至std::atomic<t></t>构造失败 - 验证是否真无锁：用
perf record -e instructions:u看热点是否集中在 cmpxchg 指令，而不是 futex_wait
最麻烦的从来不是怎么写完，而是怎么确认它在所有负载下都既正确又不退化。比如批量写入时忘了检查剩余空间分段处理，一次 push 超过缓冲区剩余容量，就会静默丢数据——这种 bug 很难复现，也很难测出来。
