【Go专家编程——并发控制——Mutex】

1.Mutex

互斥锁是并发程序中对共享资源进行访问控制的主要手段，对此Go语言提供了Mutex，对外暴露Lock()和Unlock两个方法，分别用于加锁和解锁。

1.1 Mutex的数据结构

源码如下：

type Mutex struct{state int32//代表互斥锁的状态sema uint32//表示信号量，协程阻塞等待该信号量。解锁的协程释放信号量从而唤醒等待信号量的协程
}

state表面上看起来是32位的整型变量，实际上内部分成了4部分。

• Locked：表示该Mutex是否已被锁定，0表示没有锁定，1表示已被锁定
• Woken：表示是否有协程已被唤醒，0表示没有协程唤醒，1表示已有协程唤醒，正在加锁过程中
• Starving：表示该Mutex是否处于饥饿状态，0表示没有饥饿，1表示饥饿状态，说明有协程阻塞了超过1ms
• Waiter：表示阻塞等待锁的协程个数，协程解锁时根据此值来判断是否需要释放信号量

抢锁实际上是抢给Locked赋值的权利，抢不到就阻塞等待信号量sema，一旦持有锁的协程解锁，等待的协程就会依次被唤醒。

1.2 加/解锁过程

• 简单加锁
  • locked置为1即可
• 加锁被阻塞
  • waiter+1
• 简单解锁
  • locked置为0即可
• 解锁并唤醒协程
  • locked置为0
  • 查看waiter>0
  • 释放一个信号量，唤醒一个阻塞的协程
  • 被唤醒的协程吧locked置为1

1.3 自旋过程

加锁时，如果当前Locked位为1，尝试加锁的协程不是马上转入阻塞，而是会持续地探测Locked位是否变为0，这个过程为自旋过程。

自旋时间很短，如果在自旋过程中发现锁已被释放，那么协程可以立即获取锁。此时即便有协程被唤醒也无法获取锁，只能再次阻塞（像极了被插队的情况）

1.3.1 什么是自旋

自旋对应于CPU的PAUSE指令，CPU对该指令什么也不做，相当于CPU空转，对于程序来说相当于”sleep“了一小段时间，时间很短，30个时针周期。不同于sleep，自旋不会将协程转换为睡眠状态。

1.3.2 自旋条件

加锁时程序会自动判断是否可以自旋，无限制的自旋会给CPU带来巨大压力，所以判断是否可以自旋就很重要了。
自旋必须满足以下所有的条件：

• 自旋次数要足够小，通常为4
• CPU核数要大于1，否则自旋没有意义
• 协程调度机制中的Processor数量要大于1
• 协程调度机制中的可运行队列必须为空，否则会延迟协程调用

自旋的条件很苛刻，总而言之就是不忙的时候才会启动自旋。

1.3.3 自旋的优势

自旋的优势就是更充分地利用CPU，尽量避免协程切换。经过短时间的自旋可以获得锁，就不必进入阻塞状态。

1.3.4 自旋的问题

如果自旋过程中获得锁，那么之前被阻塞的协程将无法获得锁。如果加锁的协程特别多，每次都通过自旋获得锁，那么之前被阻塞的进程将很难获得锁，从而进入了Starving状态。

1.4 Mutex模式

1.4.1 Normal模式

在该模式下，如果协程加锁不成功不会立即转入阻塞队列，而是先判断是否满足自旋状态，如果满足则会启动自旋过程，尝试加锁。

1.4.2 Starving模式（饥饿模式）

被唤醒的协程尝试加锁时发现已经被抢占了，只好再次阻塞，不过阻塞前会判断上一次阻塞距离这次阻塞的时长，如果超过1ms，则会将Mutex标记为Starving模式，然后阻塞。

在Starving模式下，不会启动自旋。

1.5 Woken状态

加锁的程序在自旋的过程中会把woken标记为1，用于通知解锁协程不需要释放信号量。

1.6 为什么重复解锁要触发panic

如果多次Unlock()，那么可能每次都释放一个信号量，这样会唤醒多个协程，多个协程被唤醒后会继续在Lock()的逻辑中抢锁，会增加Lock()实现的复杂度，也会引起不必要的协程切换。

1.7 编程Tips

• 使用defer避免死锁
  • 加锁后立即使用defer对其解锁，可以有效避免死锁
• 加锁和解锁应该成对出现
  • 加锁和解锁最好出现在同一层次的代码块中

2. RWMutex

读写互斥锁，在读取数据频率远远大于写数据频率的场景会有更好的性能。

需要解决的问题：

• 写锁阻塞写锁
• 写锁阻塞读锁
• 读锁阻塞写锁
• 读锁不阻塞读锁

2.1 读写锁的数据结构

2.1.1 数据结构

源码：

type RWMutex struct{w		Mutex		//用于控制多个写锁，获得写锁首先要获取该锁writerSem	uint32	//写阻塞等待的信号量，最后一个读者释放锁时会释放信号量readerSem	uint32	//读阻塞的协程等待的信号量，持有写锁的协程释放锁后会释放信号量readerCount	int32	//记录读者个数readerWait	int32	//记录写阻塞时读者个数
}

2.1.2 接口的定义

RWMutex提供了以下几个简单的接口：

• RLock()：读锁定
  • 增加读操作计数，readerCount++
  • 阻塞等待写操作结束（如果有）
• RUnlock()：解除读锁定
  • 减少读操作计数，readerCount–
  • 最后一个解除读锁定的协程唤醒等待写操作的协程（如果有）
• Lock()：写锁定
  • 获取互斥锁
  • 阻塞等待所有读操作结束
• Unlock()：解除写锁定
  • 唤醒因读锁定而被阻塞的协程（如果有）
  • 解除互斥锁
• TryLock()：以非阻塞方式尝试写锁定
• TryRLock()：以非阻塞方式尝试读锁定

2.2 场景分析

写操作需要等待读操作结束，写操作等待期间可能还有新的读操作持续到来。但在RWMutex中为什么写锁定不会被“饿死”？

• 因为写操作到来时，会把RWMutex.readerCount值拷贝到RWMutex.readerWait中，用于标记排在写操作前面的读者个数。
• 写操作结束后，会递减readerWait，这个值为0时唤醒写操作。