sync.Mutex在高并发下易成瓶颈，因其排他性导致读操作串行化、调度开销上升；RWMutex仅适用于读多写少且读操作真正只读的场景；atomic适用于基础类型单变量操作，性能更高但功能受限；锁粒度细化（如分片锁）可显著提升QPS，但需权衡分片数与资源消耗。
为什么 sync.Mutex 在高并发下容易成为瓶颈
因为 sync.Mutex 是排他锁，一旦某个 goroutine 持有锁，其他所有 goroutine 都得排队等待。在读多写少场景（比如计数器、配置缓存）中，读操作被强制串行化，吞吐量直接掉一半以上。Go 运行时的锁唤醒调度开销也会随竞争加剧而上升，runtime.futex 调用频繁出现就是信号。
用 sync.RWMutex 替代 sync.Mutex 的前提和陷阱
sync.RWMutex 只在读多写少且写操作不频繁时才有效。它允许多个 goroutine 同时读，但写会阻塞所有读和写。注意：如果写操作太频繁，或者读操作里隐含了写（比如读完立刻修改字段），RWMutex 不但没收益，反而因额外的锁状态管理更慢。
- 必须确保读操作是真正只读的——不能在
RWMutex.RLock()保护的代码块里调用任何可能修改共享数据的方法 -
RLock()和RUnlock()必须成对出现；漏掉RUnlock()会导致后续所有写操作永久阻塞 - 不要在 defer 中无条件调用
RUnlock()，因为RLock()失败（如被 context 取消）时不该解锁
var mu sync.RWMutex
var config map[string]string
func Get(key string) string {
mu.RLock()
defer mu.RUnlock() // ✅ 安全：只要 RLock 成功，就一定需要 RUnlock
return config[key]
}
func Set(key, value string) {
mu.Lock()
defer mu.Unlock()
config[key] = value
}
什么时候该用 atomic 而不是锁
atomic 包只适用于基础类型（int32、int64、uint32、uintptr、*T、unsafe.Pointer）的单变量读写。它比锁快一个数量级，且无 goroutine 阻塞。但无法用于结构体字段更新、多字段协调、或需要条件判断再写入的逻辑（比如“如果值为 0 才设为 1”需用 atomic.CompareAndSwapInt32）。
-
atomic.LoadInt64(&x)和atomic.StoreInt64(&x, v)是最常用、最安全的组合 - 避免对同一变量混用
atomic和非原子操作（如直接赋值x = 1），这会破坏内存可见性保证 -
atomic.Value可安全存储任意类型指针（如*Config），适合替换整个只读结构体，但每次Store都分配新对象，别在热路径反复Store
var counter int64
func Inc() {
atomic.AddInt64(&counter, 1)
}
func GetCount() int64 {
return atomic.LoadInt64(&counter)
}
锁粒度细化：从全局锁到分片锁的实际取舍
当无法避免锁，又存在明显热点（如哈希表某 bucket 冲突严重），可把一个大锁拆成多个小锁。典型做法是按 key 哈希后对 N 取模，映射到 [N]*sync.Mutex 数组。N 一般取 32 或 64——太小仍竞争，太大内存浪费且 cache line false sharing 风险上升。
立即学习“go语言免费学习笔记（深入）”；
- 分片数不宜动态调整，否则 rehash 期间需同时持有所有锁，反而更卡
- 不要用
map[int]*sync.Mutex存锁，遍历或 GC 时可能触发锁竞争；固定大小数组更可控 - 若业务允许弱一致性（如统计误差可接受），甚至可用
atomic+ 分片计数器，完全避开锁
const shardCount = 64
var shards [shardCount]struct {
mu sync.Mutex
m map[string]int
}
func Get(key string) int {
idx := int(uintptr(unsafe.Pointer(&key)) % shardCount)
shards[idx].mu.Lock()
defer shards[idx].mu.Unlock()
return shards[idx].m[key]
}
实际压测中，从全局 sync.Mutex 切到分片锁，QPS 提升常达 3–5 倍；但若分片数超过 CPU core 数太多，调度开销反而盖过收益。原子操作看似简单，但 atomic.Value 的 Store 是复制语义，大对象要小心 GC 压力。 
