Get into the habit of writing together! This is the 7th day of my participation in the "Nuggets Daily New Plan · April Update Challenge", click to view the details of the event .

Mutexes are the primary means of controlling access to shared resources in concurrent programs. Go language provides simple and easy to use for this Mutex. Mutex and Goroutine work closely together, and the concepts are easily confused. Be sure to distinguish between their concepts.

MutexIt is a structure that provides Lock()and Unlock()two methods, which are used to lock and unlock respectively.

// A Locker represents an object that can be locked and unlocked.
type Locker interface {
    Lock()
    Unlock()
}

type Mutex struct {
    state int32 
    sema  uint32
}

const (
	mutexLocked = 1 << iota // mutex is locked
	mutexWoken
	mutexStarving
	mutexWaiterShift = iota
)
复制代码

Mutex is a mutual exclusion lock, and its zero value corresponds to the unlocked state and cannot be copied;
state represents the state of the mutex, such as whether it is locked;
sema represents a semaphore, the coroutine blocking will wait for the semaphore, and the unlocked coroutine releases the semaphore to wake up the coroutine waiting for the semaphore.

Note that state is an int32 variable, which is divided into four parts during the internal implementation to record the state of the Mutex.

Locked: Indicates whether the Mutex has been locked, 0 means not locked, 1 means it has been locked;
Woken: Indicates whether a coroutine has been awakened, 0 means no coroutine is awakened, 1 means that a coroutine has been awakened and is in the process of locking;
Starving: Indicates whether the Mutex is in starvation state, 0 means no starvation, 1 means starvation state, indicating that there is a coroutine blocked for more than 1ms;

The above three represent the three states of the Mutex: locked-awaken-starved.

Although the Waiter information also exists in the state, it does not actually represent the state. It indicates the number of coroutines blocked waiting for the lock. When the coroutine is unlocked, this value is used to determine whether the semaphore needs to be released.

The lock grab between the coroutines actually competes for Lockedthe right to assign a value. If can be Lockedset to 1, it means that the lock grab is successful. If you can't grab it, block the waiting semasemaphore . Once the coroutine holding the lock is unlocked, the waiting coroutine will be awakened in turn.

Wokenand Starvingare mainly used to control the lock grabbing process between coroutines.

Lock

func (m *Mutex) Lock() {
	// Fast path: grab unlocked mutex.
	if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
		if race.Enabled {
			race.Acquire(unsafe.Pointer(m))
		}
		return
	}
	// Slow path (outlined so that the fast path can be inlined)
	m.lockSlow()
}
复制代码

若当前锁已经被使用，请求 Lock() 的 goroutine 会阻塞，直到锁可用为止。

单协程加锁

若只有一个协程加锁，无其他协程干扰，在加锁过程中会判断 Locked 标志位是否为 0，若当前为 0 则置为 1，代表加锁成功。这里本质是一个 CAS 操作，依赖了 atomic.CompareAndSwapInt32。

加锁被阻塞

假设协程B在尝试加锁前，已经有一个协程A获取到了锁，此时的状态为：

此时协程B尝试加锁，被阻塞，Mutex 的状态为：

Waiter 计数器增加了1，协程B将会持续阻塞，直到 Locked 值变成0 后才会被唤醒。

Unlock

func (m *Mutex) Unlock() {
	if race.Enabled {
		_ = m.state
		race.Release(unsafe.Pointer(m))
	}

	// Fast path: drop lock bit.
	new := atomic.AddInt32(&m.state, -mutexLocked)
	if new != 0 {
		// Outlined slow path to allow inlining the fast path.
		// To hide unlockSlow during tracing we skip one extra frame when tracing GoUnblock.
		m.unlockSlow(new)
	}
}
复制代码

如果 Mutex 没有被加锁，就直接 Unlock ，会抛出一个 runtime error。

从源码注释来看，一个 Mutex 并不会与某个特定的 goroutine 绑定，理论上讲用一个 goroutine 加锁，另一个 goroutine 解锁也是允许的，不过为了代码可维护性，一般还是建议不要这么搞。

A locked Mutex is not associated with a particular goroutine. It is allowed for one goroutine to lock a Mutex and then arrange for another goroutine to unlock it.

无协程阻塞下的解锁

假定在解锁时，没有其他协程阻塞等待加锁，那么只需要将 Locked 置为 0 即可，不需要释放信号量。

解锁并唤醒协程

假定解锁时有1个或多个协程阻塞，解锁过程分为两个步骤：

将Locked位置0；
看到 Waiter > 0，释放一个信号量，唤醒一个阻塞的协程，被唤醒的协程把 Locked 置为1，获取到锁。

自旋

加锁时，如果当前 Locked 位为1，则说明当前该锁由其他协程持有，尝试加锁的协程并不是马上转入阻塞，而是会持续探测 Locked 位是否变为0，这个过程就是「自旋」。

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

自旋的好处是，当加锁失败时不必立即转入阻塞，有一定机会获取到锁，这样可以避免一部分协程的切换。

什么是自旋

自旋对应于 CPU 的 PAUSE 指令，CPU 对该指令什么都不做，相当于空转。对程序而言相当于sleep了很小一段时间，大概 30个时钟周期。连续两次探测Locked 位的间隔就是在执行这些 PAUSE 指令，它不同于sleep，不需要将协程转为睡眠态。

自旋条件

加锁时 Golang 的 runtime 会自动判断是否可以自旋，无限制的自旋将给 CPU 带来巨大压力，自旋必须满足以下所有条件：

自旋次数要足够少，通常为 4，即自旋最多 4 次；
CPU 核数要大于 1，否则自旋没有意义，因为此时不可能有其他协程释放锁；
协程调度机制中的 P 的数量要大于 1，比如使用 GOMAXPROCS() 将处理器设置为 1 就不能启用自旋；
协程调度机制中的可运行队列必须为空，否则会延迟协程调度。

可见自旋的条件是很苛刻的，简单说就是不忙的时候才会启用自旋。

自旋的优势

自旋的优势是更充分地利用 CPU，尽量避免协程切换。因为当前申请加锁的协程拥有 CPU，如果经过短时间的自旋可以获得锁，则当前写成可以继续运行，不必进入阻塞状态。

自旋的问题

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

为此，Golang 1.8 版本后为Mutex增加了Starving模式，在这个状态下不会自旋，一旦有协程释放锁。那么一定会唤醒一个协程并成功加锁。

Mutex 的模式

每个 Mutex 都有两种模式：Normal, Starving。

Normal 模式

默认情况下的模式就是 Normal。在该模式下，协程如果加锁不成功，不会立即转入阻塞排队（先进先出），而是判断是否满足自旋条件，如果满足则会启动自旋过程，尝试抢锁。

Starving 模式

自旋过程中能抢到锁，一定意味着同一时刻有协程释放了锁。我们知道释放锁时，如果发现有阻塞等待的协程，那么还会释放一个信号量来唤醒一个等待协程，被唤醒的协程得到 CPU 后开始运行，此时发现锁已经被抢占了，自己只好再次阻塞，不过阻塞前会判断，自上次阻塞到本次阻塞经过了多长时间，如果超过 1ms，则会将 Mutex 标记为 Starving模式，然后阻塞。

在Starving模式下，不会启动自旋过程，一旦有协程释放了锁，一定会唤醒协程，被唤醒的协程将成功获取锁，同时会把等待计数减 1。

Woken 状态

Woken 状态用于加锁和解锁过程中的通信。比如，同一时刻，两个协程一个在加锁，一个在解锁，在加锁的协程可能在自旋过程中，此时把 Woken 标记为 1，用于通知解锁协程不必释放信号量，类似知会一下对方，不用释放了，我马上就拿到锁了。

Golang Mutex principle analysis