【并发编程】读写锁的实现原理（RWMutex）

博主介绍：

– 我是了 凡，喜欢每日在简书上投稿日更的读书感悟笔名：了_凡。专注于 Go Web 后端，了解过一些Python、Java、算法、前端等领域。微信公众号【了凡银河系】期待你的关注。未来大家一起加油啊~

---

前言

Mutex为了保证读写共享资源的安全性。不管读还是写都通过Mutex来保证只有一个goroutine访问共享资源，这样就会浪费，例如写少读多的情况下，即使一段时间内没有写操作，大量并发的读访问也不得不在Mutex的保护下变成了串行访问，这个时候，使用Mutex，对性能的影响就比较大。这个时候我们就可以采用区分读写操作。

如果某个读操作的goroutine持有了锁，这样的话，其它操作goroutine就不必一直等待，而且可以并发的访问共享变量，这样就可以将串行的读变成并行读，提高读操作的性能。当写操作的goroutine持有锁的时候，它就是一个排外锁，其它的写操作和读操作的goroutine，需要阻塞等待持有这个锁的goroutine释放锁。

这一类并发读写问题叫作readers-writers问题，意思是，同时可能有多个读或多个写，但是只要有一个线程执行写操作，其它的线程不能执行读写操作。

而Go标准库的RWMutex(读写锁)就是用来解决这类readers-writers问题的。接下来会介绍读写锁的使用场景、实现原理以及容易掉入的坑，避免在实际开发中犯相同的错误。

---

---

什么是RWMutex？

标准库中的RWMutex是一个reader/writer互斥锁。RWMutex在某一时刻只能由任意数量的reader持有，或者是只被单个的writer持有。

RWMutex的方法只有5个。

• Lock/Unlock:写操作时调用的方法。如果锁已经被reader或者writer持有，那么，Lock方法会一直阻塞，直到能获取锁;
  Unlock则是配对的释放锁的方法。

• Rlock/RUnlock：读操作时调用的方法。如果锁已经被writer持有的话，RLock方法会一直阻塞，直到能获取到锁，否则就直接返回；而RUnlock是reader释放锁的方法。

• RLocker：这个方法的作用是为读操作返回一个Locker接口的对象。它的Lock方法会调用RWMutex的RLock方法，它的Unlock方法会调用RWMutex的RUnlock方法。

RWMutex的零值是未加锁的状态，所以，当你使用RWMutex的时候，无论是声明变量，还是嵌入到其它的struct中，都不必显示地初始化。

假设计数器使用RWMutex保护共享资源。计数器的count ++操作是写操作，而获取count的值是读操作，这个场景很适合读写锁，因为读写锁可以并行执行，写操作时只允许一个线程执行，这正是readers-writers问题。

使用10个goroutine进行读操作，每读取一次，sleep1毫秒，同时，还有一个goroutine进行写操作，每一秒写一次，这是一个1writer-n reader 的读写场景，而且写操作还不是频繁（一秒一次）：

type Counter struct {
   mu sync.RWMutex
   count uint64
}

func main(){
   var counter Counter
   for i := 0; i < 10; i++ { // 10个reader
      go func() {
         for {
            counter.Count() // 计数器读操作
            time.Sleep(time.Millisecond)
         }
      }()
   }
   
   for {
      counter.Incr() // 计数操作
      time.Sleep(time.Second)
   }
}

// Incr 使用写锁保护
func (c *Counter) Incr()  {
   c.mu.Lock()
   c.count++
   c.mu.Unlock()
}

// Count 使用读锁保护
func (c *Counter) Count() uint64 {
   c.mu.RLocker()
   defer c.mu.RUnlock()
   return c.count
}

incr方法中count++，是一个写操作，使用Lock和Unlock进行保护。而Count方法是一个读取count值的一个操作，使用RLock/RUnlock方法进行保护。

incr方法每秒才调用一次，所以，writer竞争锁的频次是比较低的，而10个goroutine每毫秒都要执行一次查询，通过读写锁，并发的进行，可以极大提升计数器的性能。如果使用Mutex，性能就不会像读写锁这么好。因为多个reader并发读的时候，使用互斥锁导致了reader要排队读的情况，没有RWMutex并发读的性能好。

如果遇到可以明确区分reader和writer goroutine的场景，且有大量的并发读、少量的并发写，并且有强烈的性能需求，你就可以考虑使用读写锁RWMutex替换Mutex。

RWMutex的实现原理

RWMutex是很常见的并发原语，很多编程语言的库都提供了类似的并发类型。RWMutex一般都是基于互斥锁，条件变量（condition variables）或者信号量（semaphores）等并发原语来实现。Go标准库中的RWMutex是基于Mutex实现的。

readers-writers问题一般有三类，基于对读和写操作的优先级，读写锁的设计和实现也分成三类。

• Read-preferring：读优先的设计可以提供很高的并发性，但是，在竞争激烈的情况不可能导致写饥饿。这是因为，如果有大量的读，这种设计会导致只有所有的读都释放了锁之后，写才可能获取到锁。

• Writer-preferring：写优先的设计意味着，如果已经有一个writer在等待请求锁的话，它会阻止新来的请求锁的reader获取到锁，所以优先保证writer。当然，如果有一些reader已经请求了锁的话，新请求的writer也会等待已经存在的reader都释放锁之后才能获取。写优先级设计中的优先权是针对新来的请求而言的。这种设计主要避免了writer的饥饿问题。

• 不指定优先级：这种设计比较简单，不区分reader和writer优先级，某些场景下这种不指定优先级的设计反而更有效，因为第一类优先级会导致饥饿问题。

Go标准库中RWMutex设计是Write-preferring方案。一个正在阻塞的Lock调用会排除新的reader请求到锁。

RWMutex包含一个Mutex，以及四个辅助字段writerSem、readerSem、readerCount和readerWait：

type RWMutex struct{
    w   Mutex   // 互斥锁解决多个writer的竞争
    writerSem   uint32  // writer信号量
    readerSem   uint32   // reader信号量
    readerCount int32    // reader的数量
    readerWait  int32    // writer等待完成的reader的数量
}

const  rwmutexMaxReaders = 1 << 30

• 字段w：为writer的竞争锁而设计
• 字段readerCount：记录当前reader的数量（以及是否有writer竞争锁）；
• readerWait：记录writer请求锁时需要等待read完成的reader的数量；
• writerSem和readerSem：都是为了阻塞设计的信号量。

这里的常量rwmutexMaxReaders，定义了最大的reader数量。

RLock/RUnlock的实现

移除了race的等无关紧要的代码后的RLock和RUnlock方法：

func (rw *RWMutex) RLock(){
    if atomic.AddInt32($rw.readerCount, 1) < 0 {
        // rw.readerCount是负值的时候，意味着此时有writer等待请求锁，因为writer优先级
        rutime_SemacquireMutex(&rw.readerSem,false,0)
    }
}

func (rw *RWMutex) RUnlock() {
    if r := atomic.AddInt32(&rw.readerCount,-1);r < 0 {
        rw.rUnlockSlow(r) // 有等待的write
    }
}

func(rw *RWMuter) rUnlockSlow(r int32) {
    if atomic.AddInt32(&rw.readerWait, -1) == 0{
        // 最后一个reader了，writer终于有机会获得锁了
        runtime_Semrele(&)
    }
}

第2行是对reader计数加1。但是readerCount怎么还可能为负数呢？其实，这是因为，readerCount这个字段有双重含义：

• 没有writer竞争或持有锁时就，readerCount和我们正常理解的reader的计数是一样的;
• 但如果有writer竞争锁或者持有锁时，那么，readerCount不仅仅承担着reader的计数功能，还能够标识当前是否有writer竞争或持有锁，这种情况，请求锁的reader的处理进入第4行，阻塞等锁的释放。

调用RUnlock的时候，我们需要将Reader的计数减去1，因为reader的数量减少了一个。但是，第8行的AddInt32的返回值还有另外一个含义。如果它负值，就表示当前有writer竞争锁，在这种情况下，还会调用rUnlockSlow方法，检查是不是reader都释放读锁了，如果读锁都释放了，那么可以唤请求锁的writer了。

当一个或者多个reader持有锁的时候，竞争锁的writer会等待这些reader释放完，才可能持有这把锁。打个比方，在房地产行业中有条规矩叫做“买卖不破租凭”，意思是说，就算房东把房子卖了，新业主也不能把当前的租户赶走，而是等到租约结束后，才能接管房子。和RWMutex的设计是一样的。当writer请求锁的时候，是无法改变既有的reader持有锁的现实的，也不会强制这些
reader释放锁，它的优先权只是限定后来的reader不要和它抢。

rUnlockSlow将持有锁的reader计数减少1的时候，会检查既有的reaer是不是都已经释放了锁，如果都释放了锁，就会唤醒writer，让writer持有锁。

Lock

RWMutex是一个多writer多reader的读写锁，所以同时可能有多个writer和reader。那么，为了避免writer之间的竞争，RWMutex就会使用一个Mutex来保证writer的互斥。

一旦一个writer获得了内部的互斥锁，就会反转readerCount字段，把它从原本的正整数readerCount(>=0)修改为负数，让这个字段保持两个含义(既保存了reader的数量，又表示当前writer)。

第5行，还会记录当前活跃的reader数量，所谓活跃的reader，就是指持有读锁还没有释放的那些reader。

func (rw *RWMutex) Lock(){
    // 首先解决其他writer竞争问题
    rw.w.Lock()
    // 反转readerCount,告诉reader有writer竞争锁
    r := atomic.AddInt32(&rw.readerCount,-rwmutexMaxReaders) + rwmutexMaxReaders
    // 如果当前有reader持有锁，那么许哟啊等待
    if r != 0 && atomic.AddInt32(&rw.readerWait, r) != 0{
        runtime_SemacquireMutex(&rw.writerSem, false, 0)
    }
}

如果readerCount不是0，就说明当前有持有读锁的reader，RWMutex需要把这个当前readerCount赋值给readerWait字段保存下来(第7行)，同时，这个writer进入阻塞等待状态（第8行）。

每当一个reader释放锁的时候（调用RUnlock方法时），readerWait赋值给readerWait字段就减1，直到所有的活跃的reader都释放了读锁，才会唤醒这个writer。

Unlock

当一个writer释放锁的时候，它会再次反转readerCount字段。可以肯定的是，因为当前锁由writer持有，所以，readerCount字段是反转过来的，并且减去了rwmutexMaxReaders这个常数，变成了负数。所以，这里的反转方法就是给它增加rwmutexMaxReaders这个常数值。

既然writer要释放锁了，那么就需要唤醒之后新来的reader，不必再阻塞它们了，让它们开开心心地继续执行就好了。

在RWMutex的Unlock返回之前，需要把内部的互斥锁释放。释放完毕后，其他的writer才可以继续竞争这把锁。

func (rw *RWMutex) Unlock(){
    // 告诉reader没有活跃的writer了
    r := atomic.AddInt32(&rw.readerCount, rwmutexMaxReaders)
    
    // 唤醒阻塞的reader们
    for i := 0; i < int(r); i++ {
        rutime_Semrelease(&rw.readerSem, false, 0)
    }
    // 释放内部的互斥锁
    rw.w.Unlock()
}

可以看到，删除了race的处理和异常情况的检查，总体看来还是比较简单的。

注意：首先，要理解readerCount这个字段的含义以及反转方式。其次，还要注意字段的更改的内部互斥锁的顺序关系。再Lock方法中，是先获取内部互斥锁，才会修改的其他字段；而再Unlock方法中，是先修改的其他字段，才会释放内部互斥锁，这样才能保证字段的修改也受到互斥锁的保护。

---

这次就先讲到这里，如果想要了解更多的golang语言内容一键三连后序每周持续更新！

---