前言
锁作为并发编程中的关键一环，是应该要深入掌握的。
锁
示例
实现锁很简单，示例如下：
1var global int
2
3func main() {
4 var mu sync.Mutex
5 var wg sync.WaitGroup
6
7 for i := 0; i < 2; i++ {
8 wg.Add(1)
9 go func(i int) {
10 defer wg.Done()
11 mu.Lock()
12 global++
13 mu.Unlock()
14 }(i)
15 }
16
17 wg.Wait()
18 fmt.Println(global)
19}
输出：
12
在 goroutine 中给全局变量 global 加锁，实现并发顺序增加变量。其中，sync.Mutex.Lock() 对变量/临界区加锁，sync.Mutex.Unlock() 对变量/临界区解锁。
sync.Mutex
我们看 sync.Mutex 互斥锁结构：
1type Mutex struct {
2 state int32
3 sema uint32
4}
其中，state 表示锁的状态，sema 表示信号量。
进入 sync.Mutex.Lock() 查看加锁的方法。
sync.Mutex.Lock()
1func (m *Mutex) Lock() {
2 // Fast path: grab unlocked mutex.
3 if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
4 if race.Enabled {
5 race.Acquire(unsafe.Pointer(m))
6 }
7 return
8 }
9 // Slow path (outlined so that the fast path can be inlined)
10 m.lockSlow()
11}
首先进入 Fast path 逻辑，原子 CAS 操作比较锁状态 m.state 和 0，如果相等则更新当前锁为已加锁状态。这里锁标志位如下：
从低（右）到高（左）的三位表示锁状态/唤醒状态/饥饿状态：
1const (
2 mutexLocked = 1 << iota // mutex is locked
3 mutexWoken
4 mutexStarving
5)
标志位初始值为 0，1 表示状态生效。
前三位之后的位数表示排队等待锁的 goroutine 数目，总共可以允许 1«(32-3) 个 goroutine 等待锁。
这里假设有两个 goroutine G1 和 G2 抢占锁，其中 G1 通过 Fast path 获取锁，将锁的状态置为 1。这时候 G2 未获得锁，进入 Slow path：
1func (m *Mutex) lockSlow() {
2 var waitStartTime int64
3 starving := false
4 awoke := false
5 iter := 0
6 old := m.state
7 for {
8 // step1: 进入自旋
9 if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {
10 if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
11 atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
12 awoke = true
13 }
14 runtime_doSpin()
15 iter++
16 old = m.state
17 continue
18 }
19
20 ...
21 }
22}
Slow path 的代码量不大，但涉及状态转换很复杂，不容易看懂。这里拆成每个步骤，根据不同场景分析具体源码。
进入 Mutex.lockSlow()，初始化各个状态位，将当前锁状态赋给变量 old，进入 for 循环，执行第一步自旋逻辑。自旋会独占 CPU，让 CPU 空跑，但是减少了频繁切换 goroutine 带来的内存/时间消耗。如果使用的适当，会节省 CPU 开销，使用的不适当，会造成 CPU 浪费。这里进入自旋是很严苛的，通过三个条件判断能否自旋：
- 当前锁是普通模式才能进入自旋。
- runtime.sync_runtime_canSpin 需要返回 true：
- 当前 goroutine 进入自旋的次数小于 4 次；
- goroutine 运行在多 CPU 的机器上；
- 当前机器上至少存在一个正在运行的处理器 P 并且处理的运行队列为空；
假设 G2 可以进入自旋，运行 runtime_doSpin()：
1# src/runtime/lock_futex.go
2const active_spin_cnt = 30
3
4# src/runtime/proc.go
5//go:linkname sync_runtime_doSpin sync.runtime_doSpin
6//go:nosplit
7func sync_runtime_doSpin() {
8 procyield(active_spin_cnt)
9}
10
11# src/runtime/asm_amd64.s
12TEXT runtime·procyield(SB),NOSPLIT,$0-0
13 MOVL cycles+0(FP), AX
14again:
15 PAUSE
16 SUBL $1, AX
17 JNZ again
18 RET
自旋实际上是 CPU 执行了 30 次 PAUSE 指令。
自旋是在等待，等待锁释放的过程。假设在自旋期间 G1 已释放锁，更新 m.state 为 0。那么，在 G2 自旋逻辑中 old = m.state 将更新 old 为 0。继续往下看，for 循环中做了什么。
1func (m *Mutex) lockSlow() {
2 ...
3 for {
4 if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {
5 ...
6 }
7
8 // step2: 更新 new，这里 new 为 0
9 new := old
10
11 // step2: 继续更新 new
12 // - 如果锁为普通锁，更新锁状态为已锁。如果锁为饥饿锁，跳过饥饿锁更新。
13 // - 这里更新锁为 1
14 if old&mutexStarving == 0 {
15 new |= mutexLocked
16 }
17
18 // step2：继续更新 new
19 // - 如果锁为已锁或饥饿的任何一种，则更新 new 的 goroutine 排队等待位
20 // - 这里锁为已释放，new 为 1
21 if old&(mutexLocked|mutexStarving) != 0 {
22 new += 1 << mutexWaiterShift
23 }
24
25 // step2: 继续更新 new
26 // - 如果 goroutine 处于饥饿状态，并且当前锁是已锁的，更新 new 为饥饿状态
27 // - 这里锁为已释放，new 为 1
28 if starving && old&mutexLocked != 0 {
29 new |= mutexStarving
30 }
31
32 // step2: 继续更新 new
33 // - 如果当前 goroutine 是唤醒的，重置唤醒位为 0
34 // - goroutine 不是唤醒的，new 为 1
35 if awoke {
36 // The goroutine has been woken from sleep,
37 // so we need to reset the flag in either case.
38 if new&mutexWoken == 0 {
39 throw("sync: inconsistent mutex state")
40 }
41 new &^= mutexWoken
42 }
43
44 // step3: CAS 比较 m.state 和 old，如果一致则更新 m.state 到 new
45 // - 这里 m.state = 0，old = 0，new = 1
46 // - 更新 m.state 为 new，当前 goroutine 获得锁
47 if atomic.CompareAndSwapInt32(&m.state, old, new) {
48 // 如果更新锁之前的状态不是饥饿或已锁，表示当前 goroutine 已获得锁，跳出循环。
49 if old&(mutexLocked|mutexStarving) == 0 {
50 break // locked the mutex with CAS
51 }
52 ...
53 }
54 }
55}
这里将自旋后的逻辑简化为两步，更新锁的期望状态 new 和通过原子 CAS 操作更新锁。这里的场景不难，我们可以简化上述流程为如下示意图：
小结
本文介绍了 Go 互斥锁的基本结构，并且给出一个抢占互斥锁的基本场景，通过场景从源码角度分析互斥锁。