原子操作比互斥锁快2–10倍，但仅适用于int32/64等简单类型及单字段低争用场景；复合逻辑、多字段更新、条件读改写、非支持类型或需阻塞等待时必须用sync.Mutex。
原子操作比互斥锁快，但只适用于简单类型和特定场景
在 Go 中，sync/atomic 的原子操作（如 atomic.AddInt64、atomic.LoadPointer）通常比 sync.Mutex 快 2–10 倍，尤其在高并发、低争用、单字段读写场景下。但这不意味着“能用原子就不用锁”——它只支持有限类型（int32/int64/uint32/uint64/uintptr/指针），且无法保护复合逻辑或多个字段的协同更新。
什么时候必须用 sync.Mutex 而不能用原子操作
以下情况原子操作无能为力，强行硬套会导致数据竞争或逻辑错误：
- 需要同时更新两个字段（如余额 + 订单数），原子操作无法保证二者一致性
- 执行带条件判断的读-改-写（如“若 count > 0 则减 1”），
atomic.CompareAndSwap可模拟但极易写错循环逻辑 - 操作非原子支持类型：
struct、slice、map、string等，即使底层是 int 字段也不能直接原子访问其字段（除非用unsafe+ 指针偏移，不推荐） - 需阻塞等待或超时控制（原子操作永远无等待、无上下文感知）
真实压测对比：计数器场景下的吞吐差异
用 go test -bench 对比 100 万次并发自增，8 核机器典型结果：
BenchmarkAtomicAdd-8 1000000000 0.37 ns/op BenchmarkMutexAdd-8 20000000 62 ns/op
差距约 160 倍。但注意这个优势会随争用加剧而收窄——当 goroutine 频繁碰撞同一缓存行（false sharing），atomic 的性能也会陡降；而 Mutex 在严重争用时反而因内核调度更“公平”，表现更稳定。
立即学习“go语言免费学习笔记（深入）”；
关键点：
-
atomic操作本身无锁，但依赖 CPU 的LOCK前缀或LL/SC指令，本质仍是总线/缓存锁，高争用下仍影响其他核心 - 避免 false sharing：把频繁原子更新的变量单独打包成 struct，并用
//go:notinheap或填充字段隔离缓存行（如加 56 字节 padding） -
atomic.Value是特例：它支持任意类型安全发布（如配置热更新），但写入仍需外部同步，且读取是复制语义，不是引用共享
一个常见误用：用 atomic.StoreUint64 写结构体字段
下面代码看似“原子更新”，实则未定义行为：
type Config struct {
Timeout uint64
Retries uint32 // ← 与 Timeout 共享缓存行
}
var cfg Config
// 错误：直接对结构体内存地址做原子写，可能破坏 Retries 字段
atomic.StoreUint64((*uint64)(unsafe.Pointer(&cfg.Timeout)), 5000)
正确做法只有两种：
- 整个结构体用
atomic.Value替换（推荐，安全且清晰） - 用
Mutex保护整个Config实例（适合读多写少，且写操作不频繁）
真正需要极致性能又涉及结构体的场景，往往得回到内存布局+unsafe+手动对齐的老路，但可维护性代价极高，99% 的业务没必要碰。
