本文详解sync.rwmutex在嵌套读操作时因写锁抢占导致的隐式阻塞问题，揭示“读锁不互斥”假象背后的调度优先级规则，并提供安全、无锁的实践方案。
在 Go 中，sync.RWMutex 的设计原则是：多个读锁（RLock）可同时存在，读锁与写锁（Lock）互斥，写锁之间也互斥。这看似意味着连续调用 RLock 不会阻塞——但真实行为远比表面复杂。你的代码正是典型反例：
func (self *DBStore) GetString(table, key string, vargs ...interface{}) string {
self.mutex.RLock() // 第一次 RLock —— 成功获取
defer self.mutex.RUnlock()
self.Get(table, key, &output, vargs...) // 内部再次调用 RLock
return output
}
func (self *DBStore) Get(table, key string, output interface{}, vargs ...interface{}) bool {
self.mutex.RLock() // 第二次 RLock —— 可能永久阻塞！
defer self.mutex.RUnlock()
// ...
}问题核心不在“读-读冲突”，而在于 RWMutex 的公平性策略与 writer 饥饿抑制机制。Go 标准库的 RWMutex 实现（见 src/sync/rwmutex.go）明确规定：一旦有 goroutine 调用了 Lock()（请求写锁），后续所有 RLock() 调用将被阻塞，直到该写锁被释放并完成。这是为了防止写操作长期饥饿（writer starvation）。
因此，你观察到的死锁现象实际是阻塞而非死锁，其典型时序如下：
| 时间 | Goroutine | 操作 | 状态 |
|---|---|---|---|
| t₁ | G1 (GetString) | RLock() → 成功 | 持有读锁 |
| t₂ | G2 (Set, 写操作) | Lock() → 写锁入队等待 | 阻塞，但已标记 writerPending = true |
| t₃ | G1（继续执行 Get） | RLock() → 检测到 pending writer | 立即阻塞在 readerSem 上，排队等待写锁释放 |
关键点在于第 34 行源码逻辑：
立即学习“go语言免费学习笔记（深入）”；
if atomic.AddInt32(&rw.readerCount, 1) < 0 {
// writer 已存在或正在排队 → 当前 reader 必须等待
runtime_Semacquire(&rw.readerSem)
}readerCount 为负值即表示有活跃或排队的 writer。此时即使当前没有 writer 占用锁，只要队列中有 writer，新 reader 就会被挂起——RWMutex 的 reader 队列与 writer 队列共享同一调度优先级，writer 具有插入优先权。
✅ 正确解决方案有三：
-
彻底避免嵌套 RLock（推荐）
GetString 已持有读锁，Get 内部无需重复加锁。直接移除 Get 中的 RLock/RUnlock，仅保留外层保护：func (self *DBStore) GetString(table, key string, vargs ...interface{}) string { self.mutex.RLock() defer self.mutex.RUnlock() // 统一在函数退出时释放 var output string self.Get(table, key, &output, vargs...) // Get 内部无锁 return output } 使用 TryRLock + 重试（谨慎适用）
若必须动态判断，可用 TryRLock 避免阻塞，但需配合业务逻辑处理失败路径（不推荐用于数据库查询这类关键路径）。-
重构为无锁设计（最优）
数据库读操作本身是线程安全的（*sql.DB 内置连接池与并发控制），sync.RWMutex 在此处属于过度同步。应仅对内存缓存、配置状态等真正共享可变数据加锁，而非包裹 SQL 查询：// ✅ 推荐：只保护本地缓存 type DBStore struct { cache sync.Map // 或 sync.RWMutex + map[string]string db *sql.DB // *sql.DB 是并发安全的，无需额外锁 }
⚠️ 注意事项：
- sync.RWMutex 不是可重入锁（reentrant），同 goroutine 多次 RLock() 会导致阻塞；
- 日志中 "GETSTRING Got Mutex!" 后出现 "Requesting Mutex" 却无 "Got Mutex!"，正是 reader 因 writer 排队而挂起的明确信号；
- Go 1.4 版本较老（当前稳定版为 1.23+），新版本对 RWMutex 性能与公平性有优化，但仍遵循相同语义。
总结：RWMutex 的“读不互斥”仅在无 writer 干扰时成立；一旦写请求介入，所有新读者将排队等待——这不是 bug，而是为保障写操作及时性的显式设计。消除嵌套锁、厘清保护边界，才是并发安全的根本之道。
