golang的并发控制技术使用及原理（二：Mutex，RWMutex，Once）

朴灿烈づ我的快乐病毒、 2022-10-16 01:58 136阅读 0赞

go的并发控制手段有  
channel，waitgroup，context，  
sync包中的rwlock,lock,pool,Once,cond,map等。

channel，waitgroup，context，在另一篇文章中已有

这里主要是Mutex，RWMutex，Once的实现原理

**目录**

一：Mutex

底层结构

状态解释

二：RWMutex

底层结构

方法实现逻辑

阻塞分析

三：Once

底层结构

实现原理

--------------------

## 一：Mutex ##

### 底层结构 ###

type Mutex struct {
        state int32
        sema uint32
    }

一个信号量用来挂起和唤醒当前协程，一个32位的状态用来标识互斥锁的状态。  
Locked: 表示该Mutex是否已被锁定， 0： 没有锁定 1： 已被锁定。  
Woken: 表示是否有协程已被唤醒， 0： 没有协程唤醒 1： 已有协程唤醒， 正在加锁过程中。  
Starving： 表示该Mutex是否处理饥饿状态， 0： 没有饥饿 1： 饥饿状态， 说明有协程阻塞了超过1ms。  
Waiter: 表示阻塞等待锁的协程个数， 协程解锁时根据此值来判断是否需要释放信号量。

### 状态解释 ###

正常简单的加锁一般只用到locked和waiter两个状态。  
woken状态位是为了提高性能使用的状态位。  
加锁时， 如果当前Locked位为1， 说明该锁当前由其他协程持有， 尝试加锁的协程并不是马上转入阻塞， 而是会持续的探测Locked位是否变为0， 这个过程即为自旋过程。  
自旋时间很短， 但如果在自旋过程中发现锁已被释放，那么就检查该状态位，如果有自旋的，那么就不释放信号量唤醒新的协程。那么自旋的协程可以立即获取锁。 此时即便有协程被唤醒也无法获取锁， 只能再次阻塞。  
自旋的好处是， 当加锁失败时不必立即转入阻塞， 有一定机会获取到锁， 这样可以避免协程的切换。  
**自旋的条件**：  
1.自旋次数要足够小， 通常为4， 即自旋最多4次  
2.CPU核数要大于1， 否则自旋没有意义， 因为此时不可能有其他协程释放锁  
3.协程调度机制中的Process数量要大于1， 比如使用GOMAXPROCS()将处理器设置为1就不能启用自旋  
4.协程调度机制中的可运行队列必须为空， 否则会延迟协程调度  
**自旋的好处**：  
自旋的优势是更充分的利用CPU， 尽量避免协程切换。 因为当前申请加锁的协程拥有CPU， 如果经过短时间的自旋可以  
获得锁， 当前协程可以继续运行， 不必进入阻塞状态。  
**自旋的问题：**  
如果自旋过程中获得锁， 那么之前被阻塞的协程将无法获得锁， 如果加锁的协程特别多， 每次都通过自旋获得锁， 那  
么之前被阻塞的进程将很难获得锁， 从而进入饥饿状态。  
为了避免协程长时间无法获取锁， 自1.8版本以来增加了一个状态， 即Mutex的Starving状态。

Starving：默认情况下， Mutex的模式为normal。  
该模式下， 协程如果加锁不成功不会立即转入阻塞排队， 而是判断是否满足自旋的条件， 如果满足则会启动自旋过程，尝试抢锁。  
Starving模式:  
自旋过程中能抢到锁， 一定意味着同一时刻有协程释放了锁， 我们知道释放锁时如果发现有阻塞等待的协程， 还会释  
放一个信号量来唤醒一个等待协程， 被唤醒的协程得到CPU后开始运行， 此时发现锁已被抢占了， 自己只好再次阻塞，  
不过阻塞前会判断自上次阻塞到本次阻塞经过了多长时间， 如果超过1ms的话， 会将Mutex标记为”饥饿”模式， 然后  
再阻塞。  
处于饥饿模式下， 不会启动自旋过程， 也即一旦有协程释放了锁， 那么一定会唤醒协程， 被唤醒的协程将会成功获取  
锁， 同时也会把等待计数减1。

**注意点：**  
1.加锁忘记解锁会导致死锁，  
2.重复解锁会Panic  
**所以编程注意点：**  
1.加锁后立即使用defer对其解锁  
2.加锁和解锁最好出现在同一个层次的代码块中， 比如同一个函数。最好不要将锁传递出去解锁。

## 二：RWMutex ##

读写锁用于读频率大于写频率的并发访问资源的场景.  
使用读写锁， 多个读操作可以同时持有锁， 并发能力将大大提升。  
读写锁能够解决的问题：  
写锁需要阻塞写锁： 一个协程拥有写锁时， 其他协程写锁定需要阻塞  
写锁需要阻塞读锁： 一个协程拥有写锁时， 其他协程读锁定需要阻塞  
读锁需要阻塞写锁： 一个协程拥有读锁时， 其他协程写锁定需要阻塞  
读锁不能阻塞读锁： 一个协程拥有读锁时， 其他协程也可以拥有读锁

### 底层结构 ###

type RWMutex struct {
        w Mutex //写阻塞阻塞写阻塞
        writerSem uint32 //写操作被读者阻塞的信号量
        readerSem uint32 //读操作被写者阻塞的信号量
        readerCount int32 //记录读者个数
        readerWait int32 //记录写阻塞时读者个数
    }

底层结构有一个互斥锁，用于写锁阻塞写锁。  
读阻塞，写阻塞信号量，用于挂起和唤醒协程。  
以及读者个数和写阻塞时读者个数的两个计数器。用于读写锁的互相阻塞。

### 方法实现逻辑 ###

**lock：lock**时先获取互斥锁，然后readercount自减一个最大读者数量变为负值，再加回去得到最开始的readercount，判断大于0则挂起当前goroutinue，并且将最原本的readercount保存到readerwait中。（自减变为负值时为了阻塞后面的读锁，再加回去得到原来的值判断大于0则阻塞时为了被读操作阻塞自己的写操作，保存到readerwait中是为了读释放锁时释放因读阻塞的写阻塞。）

**unlock**时先自增readercount变为正值，再循环释放readercount个信号量。最后释放互斥锁。（自增readercount是为了不阻塞后面的读操作。释放readercount是为了唤醒之前挂起的读阻塞，最后释放互斥锁是为了释放写阻塞。）

**rlock**:累加readercount自增1,判断readercount<0则挂起当前协程（只被lock阻塞，lock时将该值减为负）

**runlock**:先readercount自减1，如果小于0再readerwait自减1，如果readerwait==0则释放一个写阻塞信号量。（因为不会有多个写操作因为读而阻塞，因为多个写由互斥锁阻塞。）

### 阻塞分析 ###

写操作阻塞写操作：使用互斥锁互相阻塞  
写操作阻塞读操作：利用readercount，写操作时将其减去rwmutexMaxReaders（1<<30位，即1的30次方），读操作时判断如果readercount<0则阻塞。  
读操作阻塞写操作。写操作时获取互斥锁成功后，说明没有写操作互相阻塞，然后获取readercount的大小，如果为0则阻塞自己。  
读操作不阻塞读操作，rlock时只对readercount做判断，而readercount只会被写操作减为负值。

## 三：Once ##

once用于限制只执行一次的代码，在并发过程中，多次调用只会执行第一次。后面的调用不会执行。

### 底层结构 ###

type Once struct {
        m    Mutex
        done uint32
    }

### 实现原理 ###

超级简单，利用原子操作来判断，如果已经是1了，那么直接返回，否则将值改为1，然后执行一次传入的函数。

func (o *Once) Do(f func()) {
    	if atomic.LoadUint32(&o.done) == 1 {
    		return
    	}
    	// Slow-path.
    	o.m.Lock()
    	defer o.m.Unlock()
    	if o.done == 0 {
    		defer atomic.StoreUint32(&o.done, 1)
    		f()
    	}
    }