读多写少时用 sync.Mutex 低效，因其强制所有读操作串行化；而 sync.RWMutex 允许多读并发，仅写独占，但写频繁时可能因锁升级引发饥饿。
为什么读多写少时直接用 sync.Mutex 是低效的
因为 sync.Mutex 是互斥锁，无论读还是写，都只允许一个 goroutine 进入临界区。在读多写少场景下，大量读操作被迫排队等待彼此——明明可以并发读，却硬生生串行化了。
典型现象：压测时 CPU 利用率不高，但 QPS 上不去，pprof 显示大量 goroutine 堵在 mutex.Lock() 上。
关键区别：sync.RWMutex 允许多个读 goroutine 同时进入，只有写操作会独占；只要没写操作在进行，读之间完全不阻塞。
注意：RWMutex 不是“一定更快”——如果写操作频繁（比如写占比 > 10%），它反而可能因升级锁（read → write）带来额外开销和饥饿风险。
立即学习“go语言免费学习笔记（深入）”；
RWMutex 的正确加锁姿势：读用 RLock/RUnlock，写用 Lock/Unlock
常见错误是把读操作也用 Lock，或者漏掉 RUnlock（尤其在 error 分支里），导致后续所有读写永久阻塞。
实操要点：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 读操作必须成对使用
Rlock()和RUnlock()，哪怕只读一个字段 - 写操作必须用
Lock()/Unlock()，不能混用Rlock - 禁止在持有
Rlock期间调用Lock（会死锁）；反之，持有Lock时调用Rlock无意义且多余 - 推荐用
defer mu.RUnlock()确保释放，但注意：defer 在函数 return 后才执行，若中间有 panic，仍可能漏解锁——更稳妥的是显式配对或用作用域封装
示例片段：
mu.RLock() value := m.data[key] // 只读 mu.RUnlock() // ✅ 安全；❌ 错误写法：mu.Lock() 读、或忘记 RUnlock
什么时候该考虑升级为 sync.Map 或分片锁
RWMutex 适合保护中等规模、访问模式稳定的共享数据（如配置缓存、状态映射）。但它仍是全局锁——所有读写都争抢同一把锁。
当遇到以下情况，RWMutex 就成了瓶颈：
- map 很大（> 10k 条），且读写 key 高度分散（比如用户 ID 作为 key）
- 压测显示
RWMutex的RLock调用本身开始耗时（pprof 中runtime.semasleep占比升高） - 出现写饥饿：写 goroutine 长时间等不到锁（因持续有新读请求进来）
此时可选方案：
-
sync.Map：适用于 key 动态增删、读远多于写、且不需遍历全量数据的场景；但不支持原子批量操作，遍历时无法保证一致性 - 分片
RWMutex（sharded map）：按 key 哈希到 N 个独立RWMutex+ 子 map，降低争抢；N 通常取 32 或 64，太少无效，太多内存浪费 - 读写分离 + channel 更新：写走异步 channel，读走本地 copy，适合容忍短暂 stale 的场景（如服务发现列表）
容易被忽略的陷阱：零值 RWMutex 可直接用，但别嵌套在未导出字段里暴露锁状态
sync.RWMutex 是零值安全的，声明即可用，无需 new 或初始化函数——这点常被误以为要 mu := &sync.RWMutex{}。
真正危险的是结构体设计：
- 别把
RWMutex放在 public struct 字段里（比如type Config struct { Mu sync.RWMutex; Data map[string]string }），外部代码可能直接调用c.Mu.Lock()，破坏封装和使用约定 - 应设为 unexported 字段（
mu sync.RWMutex），只暴露Get(key)/Set(key, val)方法 - 避免在方法里返回带锁保护的数据指针（如
func (c *Config) Data() *map[string]string），否则调用方可能绕过锁直接读写底层 map
最简单的防线：所有读写操作只通过方法入口，锁的生命周期完全由方法控制。
