rwmutex在读多写少时反而更慢，因其rlock/runlock需原子操作引发缓存行争用；仅当单次读耗时>100ns或含内存拷贝/函数调用才受益，写频超1%/秒易致读饥饿，且无写优先机制。
为什么 RWMutex 在读多写少时反而更慢？
不是所有“读多写少”都适合用 RWMutex —— 它的读锁共享机制有额外的原子操作开销，当读操作极短（比如只读一个 int）、且 goroutine 数量高时，RWMutex.RLock() 的自旋+原子计数可能比普通 Mutex.Lock() 更耗时。
- 典型误用场景：高频、超轻量读取（如计数器访问），配合 100+ 并发 goroutine
-
RWMutex内部用atomic.AddInt32更新 reader 计数，每次RLock/RUnlock都触发缓存行争用 - 实测差异：在 256 goroutine 读一个
int64的基准测试中，RWMutex比Mutex慢约 15%～30%
RWMutex 真正受益的读操作特征
它只在读操作本身「耗时明显」或「持有锁时间较长」时才体现价值，比如读结构体字段、解码 JSON、查 map 后做计算等。
- 推荐阈值：单次读操作平均耗时 > 100ns，或涉及内存拷贝/函数调用
- 写操作必须真正稀少——写锁阻塞所有新读请求，若写频次超过 ~1%/秒，读饥饿风险上升
- 注意
sync.Map不是替代品：它适用于「键固定、读远多于写」的场景，但不保证遍历一致性，也不能替代需要严格顺序的读写逻辑
容易被忽略的写锁饥饿陷阱
RWMutex 默认不保证写优先，大量并发 RLock 可能导致 Lock() 无限等待，尤其在持续高读负载下。
- 现象：
Lock()卡住数毫秒甚至秒级，pprof 显示 goroutine 停在runtime.semasleep - 没有内置超时或写优先开关，需自行控制：比如用
context.WithTimeout包裹写操作，并在失败后退避重试 - 临时缓解：在写操作前主动调用
runtime.Gosched()让出 P，降低读 goroutine 抢占概率（仅限紧急 workaround）
性能验证必须跑对基准测试
直接用 go test -bench 很容易得出错误结论，因为默认 B.N 是全局统一的，而 RWMutex 和 Mutex 的竞争模式完全不同。
立即学习“go语言免费学习笔记（深入）”；
- 必须分开跑：用
-run=^$排除单元测试干扰，再分别执行-bench=BenchmarkRWRead和-bench=BenchmarkMutexRead - 关键参数要匹配：goroutine 数（
-benchmem）、是否启用GOMAXPROCS、是否关闭 GC（GCPercent=-1） - 真实环境更要看
go tool trace中的阻塞事件分布，而非单纯吞吐数字 ——RWMutex可能吞吐略低，但 p99 延迟更稳
