原子操作比互斥锁快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 在严重争用时反而因内核调度更“公平”，表现更稳定。

关键点：

• 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% 的业务没必要碰。