RWMutex仅在读多写少时优于Mutex；写频繁时因原子操作、等待队列等开销反而更慢，50%读写混合下吞吐量低15–30%。
读多写少时RWMutex确实快，但写频繁时反而更慢
RWMutex不是万能加速器——它只在读操作远多于写操作的场景下比 sync.Mutex 有明显优势。一旦写操作占比升高（比如每10次读就有3次写），sync.RWMutex 的内部原子计数、读锁等待队列管理、writer-preferring 策略等开销会反超普通互斥锁。
- 写操作需将
readerCount置为负值并等待所有活跃读锁释放，这个过程比Mutex.Lock()多出至少2次原子操作 + 可能的 goroutine 唤醒延迟 - 当写请求堆积时，RWMutex 会主动阻塞新进读锁（防止写饥饿），导致本可并发的读也被串行化
- 基准测试显示：在 50% 读 + 50% 写 的混合负载下，
RWMutex吞吐量可能比Mutex低 15–30%
RLock 里做耗时操作 = 自己造“读饥饿”
读锁不阻塞其他读，但会阻塞所有写。如果 RLock() 持有时间过长（比如读完 map 后又去调用 HTTP 请求、序列化 JSON 或遍历大 slice），等于人为延长了写操作的等待窗口。
- 典型错误：
RLock()后未立即RUnlock()，而是包裹了业务逻辑甚至 IO 调用 - 后果：写协程持续 park 在
gopark，pprof 显示大量sync.runtime_SemacquireRWMutexR阻塞态 - 正确做法：只把纯粹的内存读取包进读锁，其余逻辑移出临界区
func getConfig(key string) string {
rwMu.RLock()
v := configMap[key] // ✅ 纯读
rwMu.RUnlock() // ⚠️ 必须立刻释放
// ❌ 不要在这里做：json.Marshal(v), http.Get(...), time.Sleep(10ms)
return v
}
写锁升级失败是性能隐形杀手
Go 的 sync.RWMutex 明确不支持“读锁升级为写锁”。常见错误模式是：先 RLock() 查数据，发现不存在再 RUnlock() → Lock() → 写入。这看似合理，实则埋下三重隐患：
立即学习“go语言免费学习笔记（深入）”；
- 两次加锁开销翻倍（尤其在高并发下）
- 中间窗口期存在竞态：其他 goroutine 可能在你
RUnlock()后、Lock()前完成写入，导致重复写或覆盖 - 若写逻辑含 panic，
Lock()后没defer Unlock()就永久死锁
真正安全的做法只有两种：
- 直接上写锁（适合写操作本身轻量、且命中率不低）
- 双检锁模式（适合写成本高、但读命中率极高）
func getOrSet(key, def string) string {
// 第一次检查（读锁）
rwMu.RLock()
if v, ok := cache[key]; ok {
rwMu.RUnlock()
return v
}
rwMu.RUnlock()
// 二次检查（写锁）
rwMu.Lock()
if v, ok := cache[key]; ok { // ✅ 再查一次，防竞争
rwMu.Unlock()
return v
}
cache[key] = def
rwMu.Unlock()
return def}
复制 RWMutex 或跨 goroutine 传指针 = 随机崩溃
sync.RWMutex 是非复制类型（non-copyable）。一旦被结构体字段赋值、函数参数传值、或 append 到切片，就触发隐式复制——两个副本各自维护独立的 readerCount 和信号量，锁状态完全脱节。
- 现象：程序偶发 panic “sync: negative WaitGroup counter”，或
fatal error: all goroutines are asleep - deadlock - 检测方式：启用
-race编译，运行时会报WARNING: DATA RACE并定位到复制点 - 唯一安全用法：始终以指针形式传递（
*sync.RWMutex），且确保初始化后不再复制
最容易忽略的一点：struct 字段声明为 mu sync.RWMutex（而非 mu *sync.RWMutex）时，只要该 struct 被赋值或作为参数传入，就已悄悄复制。
