Go RWMutex 写锁等待过久的竞争分析

如果 Go 服务中的写请求偶尔要等很久，先不要把原因归结为“读锁太多”。sync.RWMutex 的关键规则是：当某个 goroutine 已经调用 Lock() 并等待时，后来到达的 RLock() 也会排队，直到写者获得并释放锁。写锁等待时间因此通常由三段共同决定：正在执行的读临界区、已经获得锁的写临界区，以及锁外却被错误包进临界区的慢操作。

本文用一个带统计的最小实验把这三段拆开，再给出从日志和 mutex profile 入手的排障顺序。目标不是盲目把 RWMutex 换成别的锁，而是找到真正占用共享状态边界的代码。

官方资料：https://pkg.go.dev/sync#RWMutex

先看清写锁为什么会让新读者排队

RWMutex 可以同时容纳多个读者，或者容纳一个写者。它不是“读者永远优先”的锁：只要写者已经在等待，后来的读者就不会无限插队。这条规则保证写者最终能获得机会，但也会让读请求在写者排队期间出现一段集中等待。

因此，排障时要区分两种时间：

• 写者等待时间：从调用 Lock() 到真正拿到写锁的时间，反映前面还有多少读者或写者。
• 写者持有时间：拿到锁后到 Unlock() 的时间，反映写临界区是否做了计算、序列化、I/O 等慢操作。

如果只看接口总耗时，容易把数据库、网络或 JSON 编码的耗时误认为锁本身慢。真正要观察的是锁调用两侧的时间点。

用一个可重复实验记录读写时间

下面的示例维护一个小型配置缓存。读请求只复制必要字段，写请求先在锁外准备新值，再用很短的临界区替换。代码中的等待时间和持有时间都用 time.Since 记录，方便在真实服务中替换成指标。

package main

import (
	"fmt"
	"sync"
	"time"
)

type ConfigStore struct {
	mu   sync.RWMutex
	data map[string]string
}

func (s *ConfigStore) Get(key string) (string, time.Duration) {
	waitStart := time.Now()
	s.mu.RLock()
	wait := time.Since(waitStart)
	// 读临界区只做内存读取，避免把慢计算放进 RLock。
	value := s.data[key]
	s.mu.RUnlock()
	return value, wait
}

func (s *ConfigStore) Replace(key, value string) time.Duration {
	// 先在锁外准备数据，写锁只保护共享 map 的替换动作。
	waitStart := time.Now()
	s.mu.Lock()
	wait := time.Since(waitStart)
	holdStart := time.Now()
	s.data[key] = value
	// 记录写临界区耗时，便于和 Lock 等待时间分开分析。
	hold := time.Since(holdStart)
	s.mu.Unlock()
	fmt.Printf("write wait=%s hold=%s\\n", wait, hold)
	return wait
}

func main() {
	store := &ConfigStore{data: map[string]string{"region": "cn"}}
	var wg sync.WaitGroup
	for i := 0; i 

这个实验的重点不是某一次输出的绝对数值，而是让每条写操作都有 wait 和 hold 两个维度。如果 hold 很短但 wait 很长，优先查前方读者是否长期持有读锁；如果两者都长，先收窄写临界区；如果 wait 只在写入高峰变长，则还要看写入频率与批量更新策略。

把竞争拆成三段再定位

建议在一段短时间内同时观察下面三类数据。不要用单个平均值作结论，至少保留 p95 或 p99，才能看到偶发的长等待。

用 mutex profile 找到高竞争调用点

如果日志已经证明等待集中在某把锁上，可以临时启用 mutex 采样，观察哪些调用栈消耗了最多的阻塞时间。采样值不是每一次等待的逐条明细，应该和前面的业务字段、接口耗时一起看。

package main

import (
	"log"
	"net/http"
	_ "net/http/pprof"
	"runtime"
)

func main() {
	// 提高互斥锁阻塞采样概率，便于短时复现竞争热点。
	runtime.SetMutexProfileFraction(10)
	go func() {
		// pprof 只绑定到内部诊断端口，生产环境还应加访问控制。
		log.Println(http.ListenAndServe("127.0.0.1:6060", nil))
	}()
	select {}
}

复现期间可以采集 mutex profile，再按调用栈回到代码检查：是不是同一把全局锁保护了互不相关的键；是不是读操作先拿锁、后做昂贵转换；是不是写操作把“准备新值”和“替换共享值”混为一段。不要仅凭 profile 的排名直接改锁，先确认它与业务等待字段对应。

优先采用三种收窄竞争的方法

1. 锁外准备，锁内提交

把 JSON 解析、排序、校验和远程读取放在锁外，完成后只在锁内交换已经准备好的对象。这样做的前提是锁外构造的数据不再被并发修改。

2. 读快照，缩短读锁生命周期

如果读请求只需要一组配置，可以在锁内复制指针或必要字段，释放锁后再做格式化、过滤和响应拼装。复制本身有成本，需要以数据大小和 p95 等待为依据，不要把大对象无脑深拷贝。

3. 按独立状态拆分锁边界

一把锁保护多个互不相关的配置项时，某个热点写入会拖慢所有读者。可以按生命周期或访问热点拆分成多个存储对象，但要同步更新锁的归属说明，避免同一字段被两把锁交叉保护。

几个容易把等待问题放大的误用

• 读锁递归：一个 goroutine 已经持有 RLock，又在内部路径尝试再次 RLock，同时另一个写者正在等待，内部读锁可能无法继续获得。
• 尝试升级：不能先 RLock 再直接调用 Lock 来“升级”。应先释放读锁，再重新评估状态并获取写锁，否则容易形成等待链。
• 复制已使用的锁：RWMutex 第一次使用后不能复制。把包含它的结构体按值传递，可能让调用者和被调用者操作不同的锁。
• 忘记配对释放：所有成功的 RLock 都要对应 RUnlock，所有成功的 Lock 都要对应 Unlock；错误路径尤其要注意。

上线前的判断清单

1. 是否能分别记录读锁等待、写锁等待和持有时间？
2. 写锁等待变长时，能否指出前方是读者、写者还是锁外慢操作？
3. 读临界区是否只访问共享状态，没有网络、磁盘、日志阻塞或大循环？
4. 写临界区是否可以改成“锁外准备、锁内提交”？
5. 是否用 p95/p99 和 mutex profile 复查了优化后的结果？

常见问题

为什么读请求很多时写锁反而会等待很久？

因为写者必须等当前读者退出；如果读临界区很短，等待通常有限，但只要其中一个读者把慢操作放在锁内，写者就会被最长的那个读者拖住。

写者等待时，新读者为什么也变慢？

这是 RWMutex 防止写者持续被新读者插队的设计结果。新读者会等待写者获得并释放锁。

应该直接把 RWMutex 换成 Mutex 吗？

不能只根据“写锁等待高”做决定。先判断读临界区是否真的短、读写比例是否稳定，再用同一组负载比较两种方案的 p95 和 CPU 成本。

总结

分析 Go RWMutex 写锁等待过久时，先把时间拆成 Lock 等待、写者持有和读者持有三类，再结合 mutex profile 回到具体调用栈。最有效的改动通常是缩短临界区、锁外准备后锁内提交，以及按独立状态拆分锁边界。这样既保留读并发，也让写者能在可预期的时间内获得机会。