实时spsc不用std::queue/deque因其含锁或强一致性，引发内存屏障、原子操作及分配器竞争，延迟增2–10倍；应改用2的幂大小环形缓冲区，head/tail用relaxed原子操作+release/acquire语义，alignas(64)隔离cache line防伪共享。
为什么不用 std::queue 或 std::deque 做实时 SPSC？
因为它们内部有锁或强一致性保证，哪怕只在单线程 push、单线程 pop，也会触发内存屏障、原子操作或分配器竞争，在微秒级响应要求下拖慢 2–10 倍。实时系统里，一次缓存未命中都可能超期，更别说 malloc 或 std::mutex 的不可预测延迟。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 直接放弃所有标准容器，SPSC 场景下它们不是“够用”，而是“根本不对路”
- 必须用固定大小的环形缓冲区（circular buffer），避免动态分配
- 生产者和消费者各自独占一个索引变量（
head和tail），且仅用std::atomic的 relaxed 内存序读写 —— 这是低延迟的关键 - 不检查“空/满”状态时用模运算，改用位掩码（buffer size 必须是 2 的幂），把
%换成&，省掉除法指令
std::atomic 的 memory_order 怎么选才不翻车？
选错顺序会导致读写重排、伪共享、甚至数据覆盖——比如生产者写完数据后，消费者看到新 tail 却读到旧值，因为写数据和更新 tail 被编译器/CPU 重排了。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 生产者写数据后，用
store(tail, std::memory_order_release)；消费者读tail前，用load(std::memory_order_acquire) - 同理，消费者读数据前，用
load(head, std::memory_order_acquire)；生产者更新head后，用store(head, std::memory_order_release) - 绝对不要用
memory_order_relaxed在 head/tail 上做“比较并交换”逻辑（如判断是否可入队），它只适合纯推进索引的场景 - 如果用 GCC/Clang，加
__builtin_ia32_mfence()或std::atomic_thread_fence是过度设计，release/acquire 已足够
如何避免 ABA 问题又不引入锁？
SPSC 下其实根本不会出现 ABA：只有一个生产者改 tail，一个消费者改 head，没有第三方能反复修改同一个位置。所谓“ABA 风险”是多生产者或多消费者模型里的幻觉。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 别给
head和tail加版本号字段，那是浪费 cache line 和增加 store 带宽 - 真正要防的是“生产者追上消费者”（满）或“消费者追上生产者”（空）——靠索引差值判断，不是靠原子比较
- 如果 buffer size 是
2^N，可用(tail - head) & (size - 1)算有效长度，比if (tail >= head) ... else ...更快也更分支预测友好 - 注意：x86 上
std::atomic::load默认是 acquire 语义，但显式写出更安全，尤其跨平台时
实际部署时最容易被忽略的硬件细节
代码跑得再“无锁”，如果两个原子变量 head 和 tail 落在同一个 cache line 里，就会产生 false sharing —— 一个核改 tail，另一个核的 head 缓存副本立刻失效，频繁同步反而比锁还慢。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
alignas(64)分别对齐head和tail，确保它们不在同一 cache line（主流 CPU 是 64 字节） - 别把
head、tail和数据 buffer 放在同一个 struct 里；buffer 本身也要对齐，避免首地址跨 cache line - 在 ARM64 上，
ldar/stlr指令对应 acquire/release，没问题；但某些旧型号需确认是否支持 LSE 扩展，否则退化为 barrier + ldrex/strex - 测试时用
perf stat -e cache-misses,instructions,cycles对比有无 false sharing，miss rate > 5% 就得调对齐
最麻烦的从来不是怎么写对，而是怎么让 head 和 tail 彼此“看不见”。一旦它们开始抢 cache line，所有无锁优化就归零。
