go-deadlock 对 RWMutex 读锁无效，因其仅 hook Lock/RUnlock 等写锁路径，而 RLock 在写锁排队时直接调用未被监控的 runtime_Semacquire，不触发超时 panic。
go-deadlock 不能直接排查网络服务中 sync.rwmutex 的读锁重入隐患，它只对 sync.mutex 和 sync.rwmutex 的**写锁路径**做超时检测；而 rwmutex 读锁重入导致的阻塞，是设计机制层面的隐式排队，不是锁等待超时，go-deadlock 压根不会报警。
为什么 go-deadlock 对 RWMutex 读锁无效
go-deadlock 的原理是在调用 Lock() 或 RUnlock() 等方法前埋点，记录 goroutine 开始等待的时间。一旦超过阈值（默认 1 秒）仍未获得锁，就 panic 并打印堆栈。
但 sync.RWMutex.RLock() 在遇到已排队的写锁时，并不走常规的 mutex 等待逻辑，而是直接在 readerSem 上调用 runtime_Semacquire —— 这个信号量等待 **不被 go-deadlock hook**，因此永远不会触发超时 panic。
常见误判场景：
- goroutine A 调用了
mu.Lock()启动写操作，但未完成 - goroutine B 和 C 先后调用
mu.RLock()，均被挂起在readerSem - go-deadlock 完全沉默，pprof 却显示多个 goroutine 卡在
runtime_Semacquire或(*RWMutex).RLock
如何实际暴露 RWMutex 读锁排队问题
必须绕过 go-deadlock，改用运行时可观测性工具组合定位：
- 启动时加
import _ "net/http/pprof"，并在main()中起 pprof 服务：go http.ListenAndServe("localhost:6060", nil) - 死锁发生后（或卡顿明显时），访问
http://localhost:6060/debug/pprof/goroutine?debug=2 - 搜索关键词：
RLock、runtime_Semacquire、readerSem，确认是否多个 goroutine 停在同一行 - 再查
/debug/pprof/block，看是否有大量阻塞在sync.(*RWMutex).RLock的记录
注意：这种阻塞在日志里不叫 “deadlock”，而是 “starvation” —— 你看到的不是 panic，是服务响应变慢、goroutine 数持续上涨、CPU 却不高。
读锁嵌套调用的真实风险点
典型出问题的代码模式是方法间隐式复用同一把 RWMutex：
func (s *Service) Get(id string) string {
s.mu.RLock()
defer s.mu.RUnlock()
return s.doQuery(id) // 内部又调了 s.mu.RLock()
}
func (s *Service) doQuery(id string) string {
s.mu.RLock() // ❌ 同一 goroutine 第二次 RLock
defer s.mu.RUnlock()
// ...
}
这不是 bug，是 Go 标准库明确禁止的行为。关键判断依据不是“有没有 panic”，而是：
- pprof 显示多个 goroutine 长时间停在
(*RWMutex).RLock，且调用栈深度一致 - 写操作（
Lock()）频率低，但读请求并发一高就集体卡住 - 去掉嵌套调用、改为单次
RLock+ 手动传参后，阻塞消失
真正能预防的手段只有重构和约束
工具只能帮你发现，不能替你修复。RWMutex 的读锁排队本质是写优先策略，无法关闭。可行解法只有：
- 禁止任何方法内部再次调用同一实例的
RLock()—— 所有读操作必须在最外层一次获取，内部通过参数传递数据 - 把高频读+低频写的共享状态拆成两份：一份只读缓存（用
atomic.Value或sync.Map），一份带锁写入区 - 用
context.WithTimeout包裹外部调用链，在入口层设硬超时，避免 goroutine 长期滞留
最易被忽略的一点：这类问题在线上往往表现为“偶发延迟毛刺”，而不是崩溃，所以日志里找不到 fatal error，但 pprof 的 block profile 里早就有几十毫秒以上的阻塞记录——别等 panic 才查。
