sync.RWMutex 重复 RLock 未配对 RUnlock 会导致写锁永久阻塞，引发隐形死锁；读多写少时写饥饿、跨函数传递未释放读锁、加锁顺序不一致等均会加剧该问题。
sync.RWMutex 重复 RLock 导致写锁永久阻塞
同一个 goroutine 多次调用 RLock() 而未配对足够次数的 RUnlock()，会导致后续 Lock() 永远无法获取写锁。Go 运行时不报 panic，但协程静默卡在 mu.Lock() 上，CPU 归零、runtime.NumGoroutine() 稳定不降——这是典型的“隐形死锁”。
- 错误模式：在 defer 中无条件
RUnlock()，但RLock()因 context 超时提前返回，导致解锁多于加锁 - 安全写法：只在
RLock()成功后才安排defer mu.RUnlock()；避免在函数入口无条件加读锁 - 调试线索：pprof 查看 goroutine stack，若大量停在
(*RWMutex).Lock且调用栈含业务读逻辑，优先检查 RLock/RUnlock 配对
读多写少场景下写饥饿引发的逻辑卡死
当读请求持续密集（比如每毫秒数百次 RLock()），写操作（Lock()）可能长期抢不到锁，尤其写逻辑本身耗时（如加载远程配置）。这不是运行时 panic，但业务更新失效、监控指标停滞，容易被误判为“服务假死”。
- 写操作占比超 15%～20% 时，
sync.RWMutex的状态切换开销反而高于sync.Mutex，此时应换回普通互斥锁 - 避免在读路径中隐含写行为：例如
Get(key)里顺手更新lastAccess[key]，这会让读锁退化为写锁竞争源 - 强一致性写需求可改用双缓冲 +
atomic.Value：新数据加载完再原子切换指针，完全规避锁竞争
RLock 后 panic 导致 RUnlock 被跳过
defer mu.RUnlock() 在 panic 后仍会执行——但前提是 defer 语句已注册。如果 RLock() 后立即 panic（如 nil pointer dereference），而 defer 写在更外层函数，那本次读锁就永远泄漏。
- 必须把
defer mu.RUnlock()紧跟在mu.RLock()之后，同一作用域内 - 禁止跨函数传递未释放的读锁：不要把加了读锁的结构体传给其他函数再解锁
- 用
-race编译运行，它能捕获 “Previous read at … by goroutine N” 和 “Current write at … by goroutine M”，比等卡死再排查快得多
多个 RWMutex 间加锁顺序不一致
和普通 sync.Mutex 一样，两个 goroutine 分别按不同顺序获取两把 sync.RWMutex，也会触发 AB-BA 循环等待。运行时无法检测，现象是部分 goroutine 挂在 RLock()、部分挂在 Lock()，数量稳定不减。
- 统一加锁顺序：按变量名字母序、或按内存地址
uintptr(unsafe.Pointer(&mu1)) - 避免嵌套锁：函数 A 调 B，A 已持
mu1.RLock()，B 又尝试mu2.Lock()—— 这种调用链极易演变成循环依赖 - 关键路径上，宁可用单把粗粒度锁，也别为了“看起来并发高”而拆出多把细粒度 RWMutex 却不控序
真正难缠的不是 panic 报错的死锁，而是那些让 goroutine 数卡在 127 不动、pprof 显示全在 gopark、日志再无输出的静默卡顿——它们往往藏在 RLock/RUnlock 配对疏漏、写饥饿、或锁顺序混乱的缝隙里。
