Go sync.RWMutex RLocker 怎样复用只读锁接口

如果一个 Go 组件只接受 sync.Locker，但调用方希望它使用共享读锁，可以把 *sync.RWMutex 的 RLocker() 结果传进去。这个返回值的 Lock() 实际调用 RLock()，Unlock() 实际调用 RUnlock()，所以组件获得的是“只读锁适配器”，不是一把可以升级成写锁的普通互斥锁。

官方地址：https://pkg.go.dev/sync#RWMutex.RLocker

最重要的边界只有三条：被保护的代码只能按读者使用共享状态；需要写入时仍然直接使用原始 RWMutex；RLocker 和 RWMutex 都不能被当作可以随意复制的值。

先看 RLocker 适配了什么

sync.Locker 只有两个方法：Lock 和 Unlock。RWMutex.RLocker 返回一个实现了这个接口的锁值，它把接口方法映射到同一个 RWMutex 的读锁方法。这样，原本只会调用 Locker.Lock 的通用组件，不需要知道底层使用的是读锁。

package main

import "sync"

// ReadSection 只依赖 Locker 接口，不关心底层是 Mutex 还是 RWMutex 的读锁适配器。
func ReadSection(lock sync.Locker, read func()) {
	lock.Lock()
	defer lock.Unlock() // 保证读锁在所有返回路径释放。
	read()
}

func main() {
	var mu sync.RWMutex
	// RLocker 的 Lock/Unlock 会分别转成 mu.RLock/mu.RUnlock。
	ReadSection(mu.RLocker(), func() {
		// 这里可以读取共享数据，但不能把读锁当成写锁升级。
	})
}

代码中的关键不是把 RWMutex 转成了另一种锁，而是把“只读访问”包装成了通用组件理解的接口。调用方仍然持有原始锁对象，RLocker 只是把访问协议暴露给组件。

把只读锁交给通用组件

适配器最适合出现在“组件只需要一个锁来保护读取过程”的位置。例如，一个配置快照访问器可以只保存 sync.Locker，由外层决定它实际使用互斥锁还是读锁。这样可以减少组件与具体锁类型的耦合，同时让多个读者并发进入。

package main

import "sync"

type Snapshot struct {
	Version int
	Name    string
}

type SnapshotReader struct {
	mu   sync.Locker
	data *Snapshot
}

func NewSnapshotReader(mu *sync.RWMutex, data *Snapshot) *SnapshotReader {
	return &SnapshotReader{
		mu:   mu.RLocker(), // 组件只需要读锁接口。
		data: data,
	}
}

func (r *SnapshotReader) Read() Snapshot {
	r.mu.Lock()
	defer r.mu.Unlock() // 对应 RUnlock，不能漏掉释放。
	return *r.data       // 在读锁保护下复制一个快照返回。
}

这里返回副本是为了让调用者拿到锁外的数据，而不是把内部指针带出临界区。若 Snapshot 很大，也可以返回不可变指针或由调用者提供回调，但回调执行期间必须遵守“只读”约束。

不要把 RLocker 传给会修改 data 的组件。因为组件调用的 Lock 并不会获得写锁，它只会增加一个读者；写入期间如果没有原始 RWMutex.Lock 的保护，读写关系仍然是不安全的。

处理读者和写者的生命周期

使用 RLocker 时，读者生命周期仍然必须严格成对：接口的 Lock 与 Unlock 对应底层的 RLock 与 RUnlock。写者则继续调用原始 RWMutex 的 Lock 和 Unlock。两条访问路径必须围绕同一把锁保护同一份状态。

package main

import "sync"

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

func (s *Store) Get(key string) (string, bool) {
	// 读路径使用原始 RWMutex 的读锁，和 RLocker 的语义一致。
	s.mu.RLock()
	defer s.mu.RUnlock()
	v, ok := s.value[key]
	return v, ok
}

func (s *Store) Put(key, value string) {
	// 写路径必须拿排他锁，不能从 RLocker 上调用 Lock 期待写入互斥。
	s.mu.Lock()
	defer s.mu.Unlock()
	s.value[key] = value
}

如果某个通用组件已经持有 RLocker 对应的读锁，就不要在同一条调用链里再尝试获取写锁。RWMutex 没有把读锁“升级”为写锁的操作，直接升级会让读者等待写者、写者等待读者，形成难以恢复的阻塞关系。

哪些场景不适合用 RLocker

判断是否使用 RLocker，可以先看被适配组件对 Locker 的真实假设。

• 组件在 Lock 后会修改共享状态：不适合，应该传入原始 *sync.RWMutex 或专门的写锁接口。
• 组件需要先读后写并期待锁升级：不适合，拆成释放读锁、重新获取写锁的两个阶段，并重新确认状态。
• 组件只读取快照或遍历只读数据：通常适合，但仍要保证返回对象不会在锁外被并发修改。
• 组件需要复制锁值或把锁嵌入会被按值复制的结构：不适合，锁对象第一次使用后不应复制。

还要注意 sync.Cond 这类只接受 sync.Locker 的组件：传入 RLocker 后，条件等待会释放和重新获取读锁。只有当条件检查本身允许在读锁下完成、唤醒方使用同一状态协议时，这种组合才有意义；如果等待后需要修改状态，就应重新设计锁的边界。

用一张表记住接口映射

因此，RLocker 解决的是接口适配问题，不是锁能力扩展问题。只要通用组件的临界区确实只读，并且读写双方使用同一个 RWMutex，它就能在不暴露具体锁类型的情况下复用并发读能力。

相关问题

RLocker 的 Lock 是不是写锁？

不是。它调用的是底层 RLock，多个读者仍可并发进入，写者会等待读者退出。

能不能把 RLocker 保存成全局变量？

可以保存由同一把长期存在的 RWMutex 返回的接口，但不要复制或替换正在使用的锁对象；更清晰的做法是让拥有 RWMutex 的结构体提供读方法或构造适配器。

写入时能否继续使用 RLocker？

不能把它当写锁使用。写入路径必须使用原始 RWMutex.Lock，并与所有读路径共享同一个锁实例。