直接用 sync.Mutex 不理想，因其全局串行化读写、无法区分读读/读写冲突，扼杀 RingBuffer 并发潜力；应优先原子操作+内存序，或至少分离 readLock/writeLock。
为什么直接用 sync.Mutex 做 RingBuffer 并发控制不理想
因为 RingBuffer 的核心优势是零分配、高吞吐、低延迟，而每次读写都加锁会严重串行化生产者/消费者，尤其在多核高并发场景下，sync.Mutex 争用会成为瓶颈。更关键的是，标准互斥锁无法区分「读-读」和「读-写」冲突——而 RingBuffer 天然允许多个消费者并行读（只要不越界）、多个生产者并行写（只要不覆盖未消费数据），锁粒度太粗反而扼杀了并发潜力。
实操建议：
- 避免对整个缓冲区加一把全局锁；优先考虑原子操作 + 内存序约束
- 若必须用锁，至少拆分为
writeLock和readLock分离控制，但要注意指针推进的可见性问题 - 真正无锁（lock-free）RingBuffer 要求所有状态变更通过
atomic.LoadUint64/atomic.CompareAndSwapUint64完成，且必须严格处理 ABA 问题和内存重排序
atomic.CompareAndSwapUint64 在 RingBuffer 中怎么安全更新 head/tail
RingBuffer 的并发安全本质是协调两个游标：head（消费者已读到的位置）和 tail（生产者已写到的位置）。它们不能随意递增，必须确保：生产者写入前检查剩余空间 ≥ 1，消费者读取前检查可用数据 ≥ 1，且所有检查+推进必须是原子的。
常见错误现象：用 atomic.AddUint64 直接加 1，导致多个 goroutine 同时写入时覆盖彼此，或消费者读到未完全写入的数据。
正确做法是 CAS 循环：
// 生产者尝试推进 tail
for {
oldTail := atomic.LoadUint64(&rb.tail)
newTail := (oldTail + 1) & rb.mask
if newTail == atomic.LoadUint64(&rb.head) {
return false // 满了
}
if atomic.CompareAndSwapUint64(&rb.tail, oldTail, newTail) {
break
}
}
注意点：
-
mask = len(rb.buf) - 1要求容量必须是 2 的幂，否则位运算取模失效 - CAS 失败后必须重新 load，不能假设 oldTail 仍有效
- 消费者同理，但判断条件是
head == tail（空）而非newTail == head
为什么 RingBuffer 的读写指针要用 uint64 而不是 int
因为 int 在 32 位系统上只有 32 位，而 RingBuffer 长期运行时，head/tail 可能溢出（即使缓冲区很小）。比如每秒 100 万次写入，不到 1 小时就溢出 int32。一旦溢出，取模逻辑崩溃，(tail + 1) & mask 会计算出错误索引。
uint64 不是为“更大容量”设计的，而是为“永不溢出”设计的：按每纳秒一次写入算，也要 500 年才到上限。Go 运行时对 uint64 的原子操作有原生支持（x86-64 上是单条 cmpxchg8b 指令），而 int64 在某些平台可能触发锁总线。
使用场景提醒：
- 不要用
int或int32存游标，哪怕你确定缓冲区永远 ≤ 64KB - 所有涉及游标比较、加法、取模的地方，确保类型一致，避免隐式转换
- 调试时打印游标值用
%d即可，不需要转成int再输出
消费者如何避免读到「半写入」的数据
这是无锁 RingBuffer 最容易被忽略的坑：生产者写入一个结构体（比如 struct{ ts int64; val uint32 }）时，如果消费者在中间时刻读取，可能拿到 ts 是新值而 val 是旧值，或反之。这不是 Go 的 bug，而是 CPU 缓存一致性模型和编译器重排序共同导致的。
解决方法不是加锁，而是靠内存序 + 数据布局：
- 把「就绪标志」放在结构体最后，用单独的
uint64字段（如ready）标记该槽位是否写完；消费者先读ready，为 1 再读其余字段 - 生产者写完数据后，用
atomic.StoreUint64(&slot.ready, 1)提交，该操作带 release 语义 - 消费者读
ready时用atomic.LoadUint64(&slot.ready)，带 acquire 语义，保证后续读取能看到之前写入的数据 - 禁止编译器重排序：在写入数据和设置
ready之间插入runtime.Gosched()不解决问题，必须依赖原子操作的内存序保证
复杂点在于：每个槽位都要配一个 ready 字段，会增加内存占用；但比起锁，这是可控的代价。真正难的是测试——这种竞态极难复现，必须用 -race + 高频压测 + go test -count=100 组合验证。
