sync.RWMutex在写操作超15%～20%时通常比sync.Mutex更慢，因其读计数器原子更新及写锁需等待所有reader归零，导致高写占比或隐含写逻辑的读操作性能下降。
sync.RWMutex 在写操作超过 15%～20% 时，通常比 sync.Mutex 更慢，不是“读多写少”就该无脑换。
sync.RWMutex 什么时候反而拖慢性能
很多人一看到“读多写少”就立刻把 sync.Mutex 换成 sync.RWMutex，结果压测发现 QPS 不升反降。根本原因在于 RWMutex 的内部状态管理开销：每次 RLock/RUnlock 都要原子更新 reader 计数器，而写锁必须等待所有 reader 归零才能进入——这在高写占比或隐含写逻辑的读操作里非常致命。
- 写操作占比 >20%，比如缓存刷新、配置重载、统计聚合等场景，
sync.RWMutex的锁升级成本（从读转写）远高于sync.Mutex直接抢占 - 读函数里顺手改了
lastAccess或hitCount字段？这就不是纯读，而是“读+写”，RWMutex 会强制走写路径，放大竞争 - pprof 显示
runtime.futex占 CPU 超过 10%，基本可判定是锁争用热点，此时别猜，直接上go run -race看数据竞争报告
RLock/RUnlock 配对失败是静默死锁源
sync.RWMutex 对 RLock 和 RUnlock 的配对极其敏感，漏一次 RUnlock，后续所有 Lock 就永远卡住——而且不会 panic，也不会报错，只会在某个写请求上无限等待。
- 别在
defer m.RUnlock()里无条件解锁：如果m.RLock()因 context 超时或错误提前返回，defer仍会执行，导致计数器错乱 - 正确做法是只在
RLock成功后才安排defer，例如：if ok := m.TryRLock(); !ok { return err } defer m.RUnlock() - 用
go tool trace观察 goroutine 阻塞链，能快速定位哪个 reader 没释放
高频 map 并发访问别锁整个结构
一把 sync.RWMutex 锁住整个 map[string]interface{}，等于让所有 goroutine 排队过独木桥。真实瓶颈往往不在锁本身，而在临界区太宽。
立即学习“go语言免费学习笔记（深入）”；
- 分片锁（shard lock）是更实用的解法：按 key 哈希取模分到
shards[8]*sync.RWMutex，每个子 map 独立加锁 - 哈希必须用无符号类型，
uint32(hash) % uint32(shardCount)，否则负数索引直接 panic - 哈希函数选
fnv32或xxhash.Sum32，避免标准库 map 默认哈希的随机性导致热点集中 - 注意：分片锁不支持跨分片原子操作（如全量遍历求和），这类需求要么退化为全局锁，要么改用
atomic.Value+ 双缓冲
真正难的不是选哪种锁，而是持续判断读写比例是否稳定、临界区操作是否真的只有内存读写、以及锁持有时间是否被 IO 或计算意外拉长。一个 time.Sleep 或一次 http.Get 塞进锁里，再好的锁策略都白搭。
