std::vector和std::deque不适合高性能循环缓冲区，因其内存不连续、易触发重分配与隐式拷贝，且缺乏零拷贝读写视图；需固定大小连续内存、双原子偏移及位运算索引。
为什么 std::vector 或 std::deque 不适合做高性能循环缓冲区
因为它们默认不保证内存连续（std::deque 是分段连续）、读写时容易触发隐式拷贝或重分配，且缺乏原子性的“零拷贝”读写视图。高性能场景下，你真正需要的是：一段固定大小的连续内存 + 两个独立移动的读/写偏移 + 无需 memcpy 就能拿到数据起始地址的能力。
常见错误是用 std::vector<uint8_t></uint8_t> 手动维护 read_pos/write_pos，但每次 read() 都调用 std::copy —— 这本质还是拷贝，没解决问题。
- 真正零拷贝读写，必须返回
uint8_t*指针和长度，由上层决定是否 memcpy - 缓冲区大小必须是 2 的幂（如 4096），才能用位运算代替取模，避免分支和除法开销
- 多线程读写需额外同步，但单生产者单消费者（SPSC）场景下，可仅靠内存序 + 原子偏移实现无锁
RingBuffer::write_prepare() 和 write_commit() 分离设计的原因
这是避免数据拷贝的核心机制：不把写入封装成“一次调用完成”，而是拆成「申请可用空间指针」+「通知实际写入了多少」两步。这样上层可直接用 memcpy、DMA 写入、甚至 vectorized load/store 到返回的内存区域。
典型误用是合并成一个函数，比如 write(const void*, size_t) —— 它必然内部 memcpy，丧失零拷贝意义。
-
write_prepare()返回uint8_t*起始地址和可写长度size_t，不修改write_pos -
write_commit(size_t len)只更新write_pos，不碰内存 - 两者之间允许中断、分批写入、甚至跨函数边界（例如先 prepare，进中断处理，再 commit）
如何正确处理跨边界读写（wrap-around）而不引入分支
关键在利用 2 的幂大小 + 位掩码。假设缓冲区大小为 CAPACITY = 4096，则用 mask = CAPACITY - 1 替代 % CAPACITY。所有索引运算都用 & mask，CPU 流水线友好，无跳转预测失败开销。
但跨边界访问不能靠单指针解决：当 read_pos + len > CAPACITY，实际数据分布在尾部 + 头部两段。所以 read_peek() 必须返回两个片段：{ptr1, len1} 和 {ptr2, len2}（后者可能为 0）。
- 返回双片段结构体比抛异常或返回 nullptr 更高效，避免动态分配或错误处理分支
- 上层逻辑需主动检查
len2 > 0，决定是否 memcpy 两次（或用memmove合并） - 不要尝试用
mmap(MAP_ANONYMOUS)拼接物理页来“消除 wrap-around”——这会破坏缓存局部性，且不可移植
SPSC 场景下用 std::atomic<size_t></size_t> 但不用锁的注意事项
SPSC 是唯一能安全省掉互斥锁的常见模式。但仅靠 std::atomic<size_t></size_t> 不够，必须配合正确的内存序和读写顺序约束。
典型坑是写端 write_commit() 用 store(relaxed)，但读端未对写入内存做 load(acquire) —— 编译器或 CPU 可能重排指令，导致读到未写完的数据。
- 写端
write_commit()应用store(std::memory_order_release) - 读端
read_peek()开头对write_pos的load(std::memory_order_acquire)是必须的 - 读端
read_commit()更新read_pos也需store(std::memory_order_release) - 别依赖
std::atomic_thread_fence替代原子操作的内存序 —— 它更难验证，且现代编译器对原子操作优化更好
跨平台兼容性上，x86-64 的 acquire/release 几乎无额外指令开销，但 ARM64 需 ldar/stlr，仍远轻于 mutex。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
