atomic.addint64仅在单变量无条件增减且无false sharing时比sync.mutex快；否则易引发竞态或缓存行失效，需用独立基准测试、重置变量、隔离字段并避免跨字段逻辑。
atomic.AddInt64 在纯计数场景下确实比 sync.Mutex 快，但这个“快”是有严格前提的：只对单个 int64 字段做无条件自增/自减，且无 false sharing。一旦逻辑稍复杂，atomic 不仅不快，还可能引入竞态或性能反杀。
atomic.AddInt64 和 sync.Mutex 基准测试怎么写才靠谱
把两种实现塞进同一个 Benchmark 函数里跑，结果基本无效——变量复用、缓存残留、未重置初始值，都会污染数据。
- 必须拆成两个独立函数：
BenchmarkAtomicAdd和BenchmarkMutexAdd - 用两个隔离变量：
var atomicCounter int64和var muCounter int64，绝不共用 -
b.ResetTimer()前必须重置：atomic.StoreInt64(&atomicCounter, 0)和muCounter = 0 - 循环体内只留核心操作：
atomic.AddInt64(&atomicCounter, 1)或mu.Lock(); muCounter++; mu.Unlock() - 禁用副作用：不调
fmt.Println、不 new slice、不触发 GC
为什么高并发下 atomic 反而比 Mutex 慢
不是原子指令变慢了，而是多个 goroutine 频繁更新结构体里紧挨着的两个 int64 字段（比如 type Stats { Req int64; Err 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可能更稳——它会休眠而非持续自旋
哪些场景 atomic 不能替代 Mutex
atomic 只保证单个操作的原子性，它不是锁的轻量替代品，而是硬件级的“单指令开关”。跨出一步就失效。
-
atomic.LoadInt64读出来是 99，另一 goroutine 抢先加到 100，你再atomic.AddInt64就超了——这是典型的 ABA 问题，得用atomic.CompareAndSwapInt64或退回到Mutex - “加 1 后立刻记录日志并回调”：日志和回调不在原子范围内，
atomic完全不保护它们 - 结构体里两个
int64字段需同步更新（如count和lastUpdated）：atomic无法跨变量协调 - 涉及条件判断：“如果计数器小于 100 才加 1”——
atomic.LoadInt64+atomic.AddInt64中间可能被其他 goroutine 修改，结果不可靠
真正容易被忽略的点，是原子操作的“单字段边界”：它从来不是锁的替代品，而是一个极窄的硬件级工具。你无法用它保护 map、切片、结构体字段组合，也无法用它实现条件等待或复合逻辑。一旦需求超出 int64/uint32/*T 的范围，就得老老实实用锁——这不是性能退让，而是语义刚性。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
