什么时候该用 RWMutex 而不是 Mutex
读多写少的场景下，RWMutex 才有实际收益；如果写操作频繁（比如每秒几十次以上），它反而比 Mutex 更慢，因为内部多了读计数和唤醒逻辑。
典型适用场景：配置缓存、路由表、内存索引、状态快照等——数据被大量 goroutine 并发读取，但只由少数 goroutine 更新。
- 读操作远多于写操作（例如读:写 > 10:1）才值得引入
RWMutex - 写操作本身不能太重（
Lock()期间其他写会被阻塞，且所有新读请求也会排队） - 注意：
RWMutex不是“读不加锁”，只是允许多个读并发；它仍需显式调用RUnlock()或用defer，漏掉会导致死锁
RWMutex.RLock() 后忘记 RUnlock() 的表现
现象很隐蔽：程序不会 panic，但后续所有对同一 RWMutex 的 Lock() 会永久阻塞，而 RLock() 可能还能成功（取决于是否已有写等待）。
根本原因：RWMutex 内部靠一个原子计数器记录当前活跃读协程数；漏 RUnlock() 就导致计数器卡住，写锁永远等不到归零。
立即学习“go语言免费学习笔记（深入）”；
- 用
defer mu.RUnlock()是最安全的习惯，哪怕在 return 前有多条路径 - 不要在循环里反复
RLock()却只在循环外RUnlock()—— 这是常见误用 - 静态检查工具如
go vet不报这类问题，得靠代码审查或集成golang.org/x/tools/go/analysis/passes/inspect类自定义规则
RWMutex 和 sync.Map 到底怎么选
sync.Map 是为「键值对高频读写」优化的特殊结构，底层用了分片 + 读写分离 + 延迟清理；而 RWMutex 是通用锁，保护任意数据结构。
别被名字误导：sync.Map 不是 RWMutex 的封装，也不提供更细粒度的控制权。
- 如果你只存/取
map[interface{}]interface{}且 key 分布较均匀 → 优先试sync.Map - 如果你要保护 slice、struct、或者需要原子性地更新多个字段 → 必须用
RWMutex（或更合适的同步原语） -
sync.Map的LoadOrStore等方法开销比普通 map 查找高不少，纯读场景下不如带RWMutex的普通 map
写操作饥饿问题：为什么读太多时写一直进不去
Go 标准库的 RWMutex 实现（截至 1.23）是“读优先”的：只要还有读在进行，新来的写就得排队；而新读可以插队到正在排队的写前面。极端情况下，持续读会让写无限等待。
这不是 bug，是设计取舍。如果你的业务不能容忍写延迟，就得干预。
- 避免在长循环或网络 I/O 中持有
RLock()；把读取逻辑拆成“取数据”和“处理数据”两步，锁只包前者 - 没有内置开关关闭读优先，但可以用
sync.Mutex+ 手动读计数模拟写优先逻辑（代价是复杂度上升） - 观察
runtime.NumGoroutine()和 pprof mutex profile，确认是否存在大量 goroutine 卡在Lock()上
真正难处理的从来不是怎么加锁，而是判断哪段数据该被哪把锁保护、以及锁的生命周期是否和业务语义对齐。RWMutex 很轻，但用错位置，比不用还危险。
