Go RWMutex 为什么读锁会阻塞新读者

Go 的 RWMutex 允许多个读者同时持有读锁，但不保证新的 RLock 永远立即成功。当已有读者持锁、一个写者调用 Lock 等待时，后续读者会被挡住，直到该写者获得并释放锁。这让写者有机会完成更新，避免源源不断的读请求让它一直等待。

所以，读锁本身并不是互相排斥的写锁。出现“老读者还在读，新读者却进不来”时，要同时找等待中的写者和迟迟不释放的老读者。下面用配置中心的假设场景讨论瓶颈，不虚构线上吞吐数据或已经完成的性能测试。

Go 官方地址：https://go.dev/

规模背景：读请求很多，配置更新很少

假设服务把租户配置放在一个 map 中，读接口用 RLock，刷新接口用 Lock。平时读操作短，多个请求可以共享读锁；某个查询却在持锁期间发送网络请求或渲染大报告。只要没有写者，它的影响可能暂时不明显。

当刷新任务开始等待写锁，后续读请求也开始等待。此时即便写者的实际更新只有几行赋值，读请求延迟仍可能受那个长时间持锁的读者影响。只看读写比例，容易漏掉这个触发条件。

原架构瓶颈：等待写者改变了新读者的准入

把关系拆成三个角色更容易理解：已有读者 A 正持有 RLock；写者 W 在 Lock 中等待；后来读者 B 申请 RLock。A 不会因为 W 等待就被强制释放，但 B 不能一直插队。A 释放后，W 才有机会拿到独占锁，更新结束释放后，读者才能继续竞争。

这不是严格的业务 FIFO 队列，也不是给每个请求承诺最大等待时长。不要从这条规则推导出所有 goroutine 的完整执行顺序。排查时应关注锁持有范围与调用关系，而不是凭日志行先后猜测调度。

改造读路径：锁内复制配置，锁外执行慢操作

对于只含值字段的配置，我会优先让读方法返回一个独立值，把锁范围压到查询和复制。网络请求、模板生成、日志编码等工作使用这个局部值，避免把不确定耗时带进共享锁。

package main

import (
    "fmt"
    "sync"
)

type Config struct {
    Endpoint string
    Enabled  bool
}

type Store struct {
    mu    sync.RWMutex
    items map[string]Config
}

func (s *Store) Get(key string) (Config, bool) {
    s.mu.RLock()
    cfg, ok := s.items[key]
    s.mu.RUnlock() // 只保护 map 读取与值复制，后续处理在锁外。
    return cfg, ok
}

func (s *Store) Put(key string, cfg Config) {
    s.mu.Lock()
    defer s.mu.Unlock()
    if s.items == nil {
        s.items = make(map[string]Config)
    }
    s.items[key] = cfg
}

func describe(cfg Config) string {
    // 这里仅做文本处理；真实耗时操作也应使用锁外的局部配置。
    return fmt.Sprintf("endpoint=%s enabled=%t", cfg.Endpoint, cfg.Enabled)
}

func main() {
    var store Store
    store.Put("tenant-a", Config{Endpoint: "https://example.com/", Enabled: true})
    cfg, ok := store.Get("tenant-a")
    if !ok {
        fmt.Println("配置不存在")
        return
    }
    fmt.Println(describe(cfg))
}

这是完整的原创示例，没有在本文生成过程中运行。它演示安全的 map 访问和锁范围，不是并发性能基准。Get 返回的 Config 包含字符串和布尔值，适合按值独立使用；若改成包含 map、切片或可变指针，单纯复制外层结构体仍可能共享内部对象，需要深复制、不可变约定或额外同步。

关键取舍：别用递归读锁绕过等待

一个危险修补是认为“我已经持有读锁，再拿一次也没关系”。如果外层函数持有 RLock，又调用会获取同一把 RLock 的 Get，恰好有写者等待时，内层读锁可能阻塞，外层读锁却要等内层返回才释放，构成相互等待。sync 文档明确不允许依赖递归读锁。

应让公共方法自己加锁，并避免在持锁时调用它；确实需要组合多个字段一致读取时，把组合操作集中到一个加锁方法中，或使用清楚命名、仅限内部且要求调用方已持锁的辅助函数。不能把辅助函数暴露给不知道锁约定的调用方。

同样不能把 RLock 原地升级成 Lock。需要修改时，通常应结束读锁阶段、获取写锁并重新检查条件；两阶段之间数据可能改变，不能拿旧判断直接写入。解锁再重锁也不是原子升级。

上线后看什么：验证等待缩短，而非只看读写比例

实际改造应在相同工作负载下观察锁等待、临界区耗时和请求尾延迟，同时记录配置刷新完成时间。可以在受控环境用阻塞或互斥分析定位热点，但不能因为大多数请求是读就直接断言 RWMutex 比 Mutex 快。

还要检查一致性要求：锁外处理拿到的是某个读取时刻的配置值，不保证处理结束时仍然是最新版本。如果业务必须使用同一版本完成一组工作，可以显式带版本标识或设计快照，而不是把读锁扩展到整个外部调用。

后续改进：按共享边界选择结构

如果不同租户之间相互独立，可以评估分片锁，但跨分片操作会增加锁顺序和一致性成本。若配置更新很少、读取要求稳定快照，可以进一步评估不可变快照与原子发布；代价是复制成本、内存占用和发布规则。先缩短临界区，往往比直接替换所有同步结构更容易判断收益。

Store 中包含 RWMutex，首次使用后不能复制。方法采用指针接收者，调用方也应通过指针传递已使用的 Store。锁只保护参与同一约定的访问，不能保护绕开 Store 直接读写 items 的代码。

相关问题

只有读者、没有写者时，读锁会互斥吗？

RWMutex 支持多个读者共同持有锁。本文讨论的新读者阻塞，核心条件是写者正在申请独占访问，或已经持有写锁。

用 TryRLock 循环重试会更快吗？

忙循环不会缩短老读者的持锁时间，还会消耗 CPU。先定位长临界区和嵌套调用，再决定是否需要业务降级，不要用重试掩盖同步设计问题。

RUnlock 会释放所有读者吗？

不会。每次 RUnlock 只撤销一次读锁获取；其他并发读者仍需完成各自的释放。

参考：sync.RWMutex 官方约定、RLock 与递归读锁限制。