Go 读写锁写者等待导致读请求堆积怎么办

Go 里看到读请求突然排队，不一定是读锁“被写锁抢走”或发生了真正的读者饥饿。sync.RWMutex 的规则是：当已有读者还没退出、同时有 goroutine 等待 Lock 时，后续 RLock 会暂时阻塞，先让等待中的写者获得机会。要解决堆积，重点不是继续增加读协程，而是找出谁把读锁或写锁持有得太久。

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

为什么写者等待时读请求会堆积

下面这个现象是设计语义，不是异常：读者 A 已经拿到 RLock，写者 B 调用 Lock 后等待 A 释放；此时读者 C 再调用 RLock，不会继续加入读者队列，而是等待 B 完成。这样做是为了避免读者源源不断地进入，让写者永远等不到清空的时刻。

排查时可以把一次请求拆成三个区间：进入 RLock 前的等待、拿到读锁后的临界区、释放读锁后的业务处理。只有第一段持续增长，才说明读者被锁入口挡住；如果第二段很长，真正的问题是读临界区里做了慢工作。

缩短临界区：复制快照，锁外完成慢操作

常见改法是让锁只保护共享状态的复制。复制完成后立即释放读锁，后续过滤、编码、网络请求都在锁外完成。写路径也只在提交新快照时持有写锁，避免把业务处理时间算进锁等待。

// Snapshot 返回可独立使用的配置副本，避免把慢计算放进 RLock。
type Store struct {
	mu  sync.RWMutex
	cfg Config
}

func (s *Store) Snapshot() Config {
	s.mu.RLock()
	defer s.mu.RUnlock() // 只保护共享配置的复制
	return s.cfg.Clone() // Clone 不应回调 Store 或再次取锁
}

func handle(s *Store, w http.ResponseWriter) {
	cfg := s.Snapshot() // 读锁已释放
	body, err := render(cfg) // 允许在锁外做计算和 I/O
	if err != nil {
		http.Error(w, "render failed", http.StatusInternalServerError) // 明确返回失败
		return
	}
	_, _ = w.Write(body)
}

如果 Config 很大，复制本身也可能成为热点，可以改成不可变快照加原子替换，或把配置按独立键域分片。选择前先确认读者拿到的是一致视图，不能为了少一次锁就暴露正在修改的可变对象。

读锁递归和锁升级要单独处理

RWMutex 不支持把 RLock 升级成 Lock。更隐蔽的是递归读锁：第一次 RLock 后有写者排队，第二次 RLock 可能被挡住，而第一次读锁又等着当前调用返回，形成自我等待。把需要的数据作为参数传入、拆分“已持锁”和“自行取锁”的函数，通常比增加超时或重试更可靠。

上线前保留一个小型复盘清单：记录锁等待与锁持有的分位延迟；给写入路径标出最大临界区；确认回调不会反向访问同一把锁；当写入频率明显升高时，评估 atomic.Value 快照、分片锁或单写者模型。不要用“读多写少”四个字代替这些边界判断。

常见问题

等待中的写者会让所有已经拿到读锁的请求立刻停止吗？

不会。已经进入读临界区的调用仍需执行到 RUnlock；被挡住的是等待入口中的后续读者。

把 RLock 改成 Lock 能消除读请求堆积吗？

通常只会让读请求串行，不能修复锁内慢操作。先缩短临界区，再判断是否真的需要独占写锁。

能不能用 TryRLock 绕过等待写者？

它只能让调用方快速得到“当前拿不到锁”的结果，不能保证读取到一致数据；适合明确允许降级的场景，不是通用修复方案。