sync.rwmutex仅在读占比≥99%、写极少且不密集时才比sync.mutex快；写稍频繁（如每秒几十次）反更慢，易引发阻塞或panic，典型适用场景为配置缓存、路由快照等读远多于写的只读元数据。
sync.RWMutex 什么时候比 sync.Mutex 快
只在读操作占比 ≥99%、写操作极少且不集中爆发时，sync.RWMutex 才真能提升读性能。写操作哪怕每秒几十次，RWMutex 的内部计数器和唤醒开销就可能拖垮吞吐，比 sync.Mutex 还慢。
常见误判点：以为“读多”就够了，但没看写是否「密集」。比如配置热重载触发批量更新，瞬间涌进 50 次 Lock()，后续所有 RLock() 都会排队，读延迟从微秒级跳到百毫秒级。
- 符合场景：
map[string]*User缓存（启动后只读，定时全量刷新）、路由快照、静态资源元信息索引 - 反例场景：高频计数器、实时消费位点、日志缓冲区 —— 这些写锁一竞争，
RWMutex就失效 - 压测时若看到 CPU 不高但写吞吐上不去、
runtime.semacquire等待陡增，大概率是写被阻塞了
RLock() 和 Lock() 不能混用或嵌套调用
RLock() 后不能直接调用 Lock()，Go 不支持读锁升级。当前 goroutine 已持读锁，再调 Lock() 会永久阻塞 —— 死锁。
典型错误写法：
rw.RLock() defer rw.RUnlock() // … 读完发现要改 rw.Lock() // ❌ 死锁！
正确做法只有两种：
- 先
RUnlock()，再Lock()，重读+写入（适合读快、写少、条件写） - 一开始就不加读锁，直接
Lock()（适合逻辑不确定是否要写，或写路径占比不低）
嵌入结构体时必须用指针接收器
sync.RWMutex 是值类型，如果作为结构体字段却用了值接收器方法，每次调用都会复制锁对象，加锁完全无效。
错例：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func (s MyConfig) Get() string {
s.mu.RLock() // s.mu 是副本！
defer s.mu.RUnlock()
return s.data
}
正解：
func (s *MyConfig) Get() string {
s.mu.RLock() // mu 在原始结构体上
defer s.mu.RUnlock()
return s.data
}
额外提醒：RWMutex 零值可用，无需显式初始化，但必须通过指针访问才能生效。
RUnlock() panic: “sync: RUnlock of unlocked RWMutex” 怎么定位
这不是“没加锁”，而是“多解了一次”或“在没加锁的路径上调了 RUnlock()”。最常见于 defer 写在外层，但 RLock() 在某个 if 分支里 —— 分支没走，defer 却执行了。
高危模式：
-
errorearly return 路径漏掉RUnlock() - 循环体内反复
RLock()/RUnlock()，粒度太细易配对失败 - 多个
return分支，只在一处defer，其他分支未覆盖
调试建议：用 go build -race 运行，竞态检测器会直接标出不匹配的锁操作位置。
真正难处理的不是加锁本身，而是写操作突发时读延迟不可控 —— 它不会报错，也不会 panic，只会让 P99 延迟悄悄飘高，而且很难复现。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
