rwmutex比mutex快是因为允许多个goroutine并发读，仅写操作独占；适用于读远多于写的场景，但需正确配对rlock/runlock，避免误用导致阻塞或性能下降。
为什么读多写少时 RWMutex 比 Mutex 更快
因为 RWMutex 允许多个 goroutine 同时读，但写操作会独占；而 Mutex 无论读写都串行。在读操作远多于写操作的场景（比如配置缓存、状态快照），用 RWMutex 能显著减少 goroutine 阻塞等待时间。
但要注意：它不是“自动优化”，必须手动把读逻辑套进 RUnlock() 前的临界区，否则反而更慢——因为多了额外的锁状态判断开销。
- 读操作用
RLock()/RUnlock()，写操作用Lock()/Unlock() -
RWMutex的写操作会阻塞新来的读和写，已持有的读锁不释放前，写会一直等待 - 如果读操作里有耗时逻辑（比如网络调用、大对象深拷贝），别把它包进
RUnlock()前——这会让其他读也卡住
RWMutex 的典型误用：读锁没及时释放
最常见的错误是 defer RUnlock() 写错位置，或在循环/条件分支里漏掉释放。一旦某个 goroutine 持有读锁不放，后续所有写操作都会 hang 住，连带新的读也可能被饿死（取决于实现细节和竞争强度）。
例如下面这段代码：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
// ❌ 错误：defer 在函数开头就注册，但实际可能根本没走到 RLock()
func badRead(m *sync.RWMutex, data *map[string]int) {
defer m.RUnlock() // 这里 panic：unlock of unlocked RWMutex
m.RLock()
fmt.Println(*data)
}
正确写法是确保 RUnlock() 一定跟在对应 RLock() 后，且只释放本 goroutine 拿到的锁：
// ✅ 正确：RLock 和 RUnlock 成对、就近
func goodRead(m *sync.RWMutex, data *map[string]int) {
m.RLock()
defer m.RUnlock()
fmt.Println(*data)
}
什么时候不该用 RWMutex
不是所有“读多”场景都适合 RWMutex。它的内部状态维护比 Mutex 复杂，当读操作本身极轻量（比如读一个 int 字段）、且并发度不高时，RWMutex 反而因额外原子操作带来更高开销。
- 单核 CPU 或 goroutine 数远小于逻辑 CPU 数时，锁竞争本就不激烈，换
RWMutex几乎无收益 - 写操作频繁（比如每秒上百次），读锁的“批量通过”优势会被写饥饿抵消，甚至导致读延迟毛刺增大
- 需要精确控制读写顺序（如强一致性要求），
RWMutex不保证读操作看到的是同一时刻的快照，它只保证读期间不被写打断
RWMutex 和 sync.Map 怎么选
sync.Map 是为高并发读写设计的无锁哈希表，但它不支持遍历、不支持自定义比较逻辑，且 key 必须是可比较类型。而 RWMutex + 普通 map 是通用解法，可控性强。
- 如果你只是读写一个
map[string]interface{}，且读占比 >95%，RWMutex+map更直观、内存更省、GC 压力更小 - 如果你要做大量并发 put/get 且 key 类型固定，又不需要 range 或 len，
sync.Map可能略快，但调试难度上升（比如无法直接打印内部结构） - 注意：
sync.Map的Load不加锁，但底层仍可能触发内存屏障或原子读，不是零成本；别以为它完全替代了RWMutex
真正难处理的是读写混合中带复杂逻辑的场景——比如读的时候要校验再写，这时候 RWMutex 很容易陷入“先读后写”的锁升级陷阱，得手动降级或换用更细粒度的锁策略。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
