热路径下读写比低于8:1时优先用sync.Mutex；RWMutex仅适用于读占比超90%且写操作稀疏的场景，如元数据缓存、监控只读视图、长周期静态配置；写密集时易引发写者饥饿，导致延迟激增；严禁RLock后直接Lock，须先RUnlock再Lock或改用双检查模式；锁粒度优化（如分片锁、atomic、chan异步）比锁类型选择更重要。
热路径下读写比低于 8:1，优先用 sync.Mutex
实测表明，当读操作占比不到 90%（即读写比 sync.Mutex 的 P99 延迟更稳、吞吐更可靠。RWMutex 内部要维护 readerCount、readerWait、两个信号量和一个嵌套 w *Mutex，这些额外状态在中低竞争下反成负担。
常见误判场景：
- 以为“读多”就该上 RWMutex，结果接口压测发现 QPS 不升反降 —— 很可能读写比实际只有 3:1 或写请求突发集中
- 配置服务标称“只读高频”，但后台有定时批量刷新（每秒数次写），导致新读请求被阻塞在
RLock()，出现延迟毛刺 - 用
go tool pprof看到runtime_Semacquire占比异常高，大概率是 RWMutex 的readerSem或writerSem在争抢
sync.RWMutex 只在明确读多写少且写不爆发时才值得引入
它不是“高级版 Mutex”，而是一个有严格适用边界的专用工具。真实收益只出现在：读操作占绝对主导（≥ 90%）、写操作极少（如配置热更新间隔 > 30 秒）、且写操作之间无强顺序依赖的场景。
典型可用案例：
立即学习“go语言免费学习笔记（深入）”；
- 服务启动后只读的元数据缓存（如 OpenAPI Schema、路由表快照）
- 监控指标只读视图（
atomic.Value+ 不可变结构体更优，但 RWMutex 是兼容 fallback） - 长周期静态配置（如限流规则、黑白名单），更新频率远低于查询频率（比如 1 次/小时 vs 1000 次/秒）
一旦写操作开始密集（如每秒多次 Lock()），RWMutex 的写者饥饿机制会拖慢整体响应，甚至让读延迟从毫秒级跳到百毫秒级。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
别在热路径里尝试锁升级：RWMutex.RLock() 后不能直接 Lock()
这是线上死锁最高发的坑。Go 不支持任何锁升级语义，RWMutex 也没有 Upgrade() 方法。下面这段代码在热路径里等于埋雷：
func badHotPath() {
rwMu.RLock()
defer rwMu.RUnlock()
if needWrite() {
rwMu.Lock() // ⚠️ 永远卡住：当前 goroutine 还持有 RLock，无法获取写锁
// ...
rwMu.Unlock()
}
}
正确做法只有两种：
- 先显式
rwMu.RUnlock()，再rwMu.Lock()（注意：必须确保中间无竞态） - 改用双检查模式（double-check），把读判断和写逻辑拆成两个独立临界区
更重要的是：热路径里应尽量避免这种“先读后写”的分支逻辑。若频繁发生，说明数据结构或访问模式本身就不适合 RWMutex。
锁粒度比锁类型更能决定热路径性能
换 RWMutex 却没提速？八成是因为临界区太大。比如在 RLock() 里做了 HTTP 调用、数据库查询或复杂 JSON 序列化 —— 这些本该移出临界区的操作，会让所有并发读都被迫排队等 IO 完成。
真正有效的优化方向：
- 把大锁拆成哈希分片锁（如按
user_id % 16分 16 把Mutex），哪怕只用sync.Mutex也能提升数倍并发能力 - 读操作能用
atomic.LoadUint64或atomic.Value的，坚决不用锁（计数器、开关标志、不可变配置快照） - 写操作若只是追加日志或发消息，考虑用
chan异步投递，彻底退出共享内存竞争
锁类型选错最多损失 10%～20% 性能；锁粒度失控，会让热路径直接退化成单线程执行。
