sync.Mutex 和 sync.RWMutex 不适合高频计数场景，因其锁开销大、多核争抢易触发自旋休眠切换，吞吐仅为 atomic.AddInt64 的 1/5～1/3；RWMutex 在读少写多时更重，且 atomic 无法支持复合操作或条件逻辑，此时需 Mutex 兜底。
为什么 sync.Mutex 和 sync.RWMutex 不适合高频计数场景
因为锁的开销在高并发、高频更新下会成为瓶颈：每次 Lock()/Unlock() 都涉及系统调用或调度器介入，尤其在多核争抢时容易触发自旋+休眠切换。实测中，100 个 goroutine 每秒百万次递增，sync.Mutex 吞吐量可能只有 atomic.AddInt64 的 1/5～1/3。
另外 sync.RWMutex 对写操作无帮助——计数器几乎全是写（Inc），读少写多时它反而比普通互斥锁更重。
- 不要用
RWMutex做纯计数器，读写比例低于 1:10 就不划算 - 避免在 hot path（如 HTTP handler 内部循环）中嵌套锁
- 如果计数器还需支持「重置」或「条件递增」，锁仍是必要兜底，但基础累加优先走原子操作
atomic 包能安全做哪些事？不能做哪些事？
atomic 提供的是底层 CPU 指令级的原子读写与运算，适用于单个整数、指针、unsafe.Pointer 的简单操作。它快、无锁、可伸缩性好，但能力有限：
- ✅ 支持：
atomic.AddInt64、atomic.LoadInt64、atomic.StoreInt64、atomic.CompareAndSwapInt64 - ❌ 不支持：复合操作（如「先读再加再存」非原子）、浮点数（需转整型位模式处理）、结构体字段批量更新
- ⚠️ 注意：
atomic对变量地址有严格要求——必须是 64 位对齐的全局变量或结构体首字段；在 32 位系统上操作int64可能 panic
示例：一个典型安全计数器
立即学习“go语言免费学习笔记（深入）”；
type Counter struct {
val int64
}
func (c *Counter) Inc() {
atomic.AddInt64(&c.val, 1)
}
func (c *Counter) Load() int64 {
return atomic.LoadInt64(&c.val)
}
什么时候必须用 sync.Mutex 替代原子操作？
当计数逻辑超出原子指令能力边界时，比如需要「读-改-写」语义、依赖外部状态判断、或维护多个关联字段的一致性。
- 实现「带阈值的计数器」：超过 1000 才触发告警 → 必须
Load+ 判断 +Store，中间可能被其他 goroutine 插入修改，需锁保证原子性 - 计数器带时间戳字段：
count和lastUpdated必须同时更新，否则出现脏读 - 需要阻塞等待（如限流器中的 token 消耗），
atomic无法挂起 goroutine
此时正确做法是封装临界区：
type SafeCounter struct {
mu sync.Mutex
count int64
limit int64
}
func (s *SafeCounter) TryInc() bool {
s.mu.Lock()
defer s.mu.Unlock()
if s.count < s.limit {
s.count++
return true
}
return false
}
性能差异真实影响在哪？别只看 microbenchmarks
基准测试（如 go test -bench）显示 atomic 比锁快 5–10 倍，但这只是理想线性场景。真实服务中更关键的是「可伸缩性拐点」：当 goroutine 数从 10 升到 1000，atomic 吞吐基本线性增长，而锁可能在 200 goroutine 附近就因调度抖动开始掉速。
另一个常被忽略的点是 GC 压力：sync.Mutex 内部含 sema 字段，在极端争抢下可能触发更多 runtime.semawakeup 调用，间接增加调度器负担；atomic 完全不参与调度，对 GC 友好。
最终选择不是非此即彼——高频累加用 atomic，复杂策略兜底用 sync.Mutex，两者混用才是常态。真正容易出错的，是在原子操作里偷偷嵌套了非原子的条件分支。
