sync.RWMutex在写操作超15%时性能劣于Mutex，易致写饥饿；推荐atomic.Value替代全量更新、分片锁分散竞争，并严防锁泄漏与嵌套死锁。
sync.RWMutex 在高并发写操作场景下不是最优解——它会退化成串行瓶颈，且容易引发写饥饿、锁泄漏或隐性死锁。
写操作占比超 15% 时，sync.RWMutex 反而比 sync.Mutex 更慢
读写锁的内部状态切换（从读态转写态）开销显著高于普通互斥锁。当写请求频繁（比如配置热更新、实时指标聚合），RWMutex 的 Lock() 会不断等待所有活跃读锁释放，而新进读请求又持续抢占，形成“写被压在队尾”的假性卡顿。
- 实测表明：写操作占比 ≥ 20% 时，
RWMutex平均延迟比Mutex高 3–5 倍 - pprof 中常表现为大量 goroutine 停留在
(*RWMutex).Lock，但RLock调用栈却异常活跃 - 若写逻辑本身耗时（如 HTTP 请求、磁盘写入），问题会被放大——不是锁慢，而是写永远抢不到机会
atomic.Value 替代写锁：适用于只读高频 + 偶尔全量更新
当写操作是“整体替换”而非“字段修改”（如加载新配置、刷新路由表），atomic.Value 能彻底避开锁竞争，且保证读操作零开销。
- 写端：构造新结构体 →
store()原子切换指针 - 读端：直接
load()，无锁、无内存屏障开销 - 注意：
atomic.Value只支持interface{}，需类型断言；不支持部分字段更新 - 示例：
var cfg atomic.Value; cfg.Store(&Config{...})，读取时cfg.Load().(*Config)
写操作无法避免时，优先用分片锁（Shard Lock）而非全局锁
把一个大资源拆成多个独立子单元，每个单元配独立 sync.Mutex，让写操作分散到不同锁上，天然降低冲突概率。
- 典型场景：高频写入的
map[string]int，按 key 哈希到 64 个分片，写key="user_123"只锁第 3 片 - 避免使用
sync.Map：它对写优化有限，且 API 不支持遍历、len() 不准确，调试困难 - 分片数不宜过小（ 256）；推荐 64 或 128，平衡内存与竞争
- 关键点：哈希函数必须稳定（如
fnv32(key) % shardCount），且分片锁不能跨 goroutine 传递
defer mu.Unlock() 必须紧跟 mu.Lock()，尤其在写路径中
写操作通常伴随 IO、网络调用或 panic 风险，defer 位置错位会导致锁永久泄漏，后续所有写/读都被阻塞。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
mu.Lock(); if err != nil { return }; defer mu.Unlock()—— err 分支跳过 defer - 正确写法：始终把
defer mu.Unlock()紧跟在mu.Lock()后，同一作用域内 - 更安全：用
go run -race编译运行，它能捕获 “Unlock not called” 类型的漏锁 - 写路径中禁止嵌套加锁：A 函数已持
mu1，再调 B 函数并尝试mu2.Lock()，极易演变成 AB-BA 死锁
