RWMutex的RLock在高并发下可能比Mutex更慢，因其每次调用需原子增计数并检查写等待，开销大于Mutex的单次CAS；写请求排队时新读请求被阻塞在readerSem，短生命周期读goroutine还可能引发隐式读饥饿；读锁若包裹IO或重计算，会阻塞所有写操作；实测仅读占比≥70%时RWMutex才显著优于Mutex，低于40%时反而更差。
RWMutex 的读锁（RLock）不是无成本的，高并发下它可能比 Mutex 还慢——尤其当写请求排队或读操作本身不轻量时。
RLock 为什么会在高并发下变慢
每次调用 RLock() 都要执行原子操作 + 条件判断：先 atomic.AddInt32(&rw.readerCount, 1)，再检查是否为负值（表示有 writer pending）。这比 Mutex.Lock() 的单次 CAS 开销更大。
- 写请求一旦调用
Lock()，后续所有RLock()都会被阻塞在readerSem上，排队等待——不是“只等当前写完”，而是“等写入队列清空” - 大量短生命周期读 goroutine 持续抢占
readerSem，反而把写 goroutine “挤”在调度队列尾部，造成隐式读饥饿 - pprof 中若看到高频调用
runtime_Semacquire或runtime.semasleep，基本可判定是RLock()在排队
读锁持有时间过长直接拖垮写吞吐
RWMutex 的写锁必须等所有已持有的读锁释放后才能获取。哪怕只有一个 RLock() 后做了 http.Get、json.Marshal 或遍历大 slice，所有 Lock() 就会卡住。
- 典型错误：
RLock()→ 网络调用 →RUnlock()（❌ 不允许） - 正确做法：只在
RLock()临界区内做纯内存访问；IO 或计算应提前复制数据或移出锁外 - 压测中若发现写延迟突增、
runtime.NumGoroutine()持续上涨，大概率是读锁持有时间失控
读占比低于 70% 时 RLock 反而更危险
Go 1.22 实测表明：RWMutex 仅在读操作 ≥ 70% 时吞吐显著优于 Mutex；读占比掉到 40% 以下时，RLock() 的状态检查开销 + 排队放大效应会让整体性能反超 Mutex。
- 别只看“读多”，要看“读是否轻量”和“写是否偶发”——写占比 > 30% 就该警惕
- 含「读→判断→写」逻辑（如懒加载初始化）的场景，
RLock()极易引发死锁，此时必须退回到Mutex - 用
go tool trace观察sync/block事件，比凭感觉判断读写比例更可靠
真正卡住系统的，往往不是锁类型选错，而是把耗时操作塞进了 RLock() 和 RUnlock() 之间——这个边界一旦模糊，RWMutex 就从优化手段变成性能黑洞。
