atomic比Mutex快因其实现于硬件指令（如LOCK XADD），纯用户态执行、无上下文切换；而Mutex需系统调用、线程挂起与唤醒，开销高数十倍。
atomic 操作在纯数值读写场景下确实比 Mutex 快得多，但直接拿 atomic.AddInt64 和 mu.Lock() 对比性能，十有八九测歪了——不是原子操作慢，是测试方法本身污染了结果。
基准测试必须拆成两个独立函数
把 atomic.AddInt64 和 mu.Lock() 塞进同一个 Benchmark 函数里跑，变量复用、缓存残留、初始化未重置，都会让数据失真。必须严格隔离：
- 用两个独立变量：
var atomicCounter int64和var muCounter int64，绝不能共用一个counter - 每次 benchmark 迭代前重置值：
atomic.StoreInt64(&atomicCounter, 0)和muCounter = 0（注意：这步得在b.ResetTimer()之前完成） - 循环体内只放核心操作：
atomic.AddInt64(&atomicCounter, 1)或mu.Lock(); muCounter++; mu.Unlock() - 禁用任何副作用：不打印、不分配 slice、不调用带锁的辅助函数
atomic.LoadInt64 读快，但不等于“能随便换”
atomic.LoadInt64 是单条 CPU 指令（如 ldxr），延迟通常 1–3 ns；而 RWMutex.RLock() 即使无争用也要走 CAS、队列检查，实测常在 8–20 ns。但这只适用于“孤立读”：
- 读完立刻做判断再写（比如
if atomic.LoadInt64(&x) == 0 { x = 1 }）→ 竞态暴露，必须换atomic.CompareAndSwapInt64或锁 - 读多个字段（
atomic.LoadInt64(&a)和atomic.LoadInt64(&b)）期望它们“配对”→ 中间可能被其他 goroutine 只改了其中一个，一致性断裂
高争用下 atomic.AddInt64 反而更慢？先查 false sharing
不是原子指令变慢了，而是多个 goroutine 频繁更新结构体里紧挨着的两个 int64 字段，导致它们落在同一 CPU 缓存行（64 字节）。每次写都会让其他 core 的副本失效，引发大量缓存同步开销。
- 验证方式：
go tool trace看到runtime.usleep和sync.runtime_SemacquireMutex占比都很低，却出现大量自旋等待 → 大概率是 false sharing - 解决办法：给原子字段前后加
[12]byte填充，或用 Go 1.21+ 的atomic.Int64类型（它内部已做 cache-line 对齐） - 注意：如果写操作占比超过 15%，且 goroutine 数远超 CPU 核数，
sync.Mutex可能更稳——它会休眠而非持续自旋
真正容易被忽略的点，是原子操作的“单字段边界”：它从来不是锁的替代品，而是一个极窄的硬件级工具。你无法用它保护 map、切片、结构体字段组合，也无法用它实现条件等待或复合逻辑。一旦需求超出 int64 / uint32 / *T 的范围，就得老老实实用锁——这不是性能退让，而是语义刚性。
