17370845950

本文详解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）。

因此，你观察到的死锁现象实际是阻塞而非死锁，其典型时序如下：

关键点在于第 34 行源码逻辑：

if atomic.AddInt32(&rw.readerCount, 1) < 0 {
    // writer 已存在或正在排队 → 当前 reader 必须等待
    runtime_Semacquire(&rw.readerSem)
}

readerCount 为负值即表示有活跃或排队的 writer。此时即使当前没有 writer 占用锁，只要队列中有 writer，新 reader 就会被挂起——RWMutex 的 reader 队列与 writer 队列共享同一调度优先级，writer 具有插入优先权。

✅ 正确解决方案有三：

1. 彻底避免嵌套 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
   }

2. 使用 TryRLock + 重试（谨慎适用）
   若必须动态判断，可用 TryRLock 避免阻塞，但需配合业务逻辑处理失败路径（不推荐用于数据库查询这类关键路径）。

3. 重构为无锁设计（最优）
   数据库读操作本身是线程安全的（*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，而是为保障写操作及时性的显式设计。消除嵌套锁、厘清保护边界，才是并发安全的根本之道。