2. 同步原语与锁

同步原语与锁 #

2.1. 概述 #

​ 本节会介绍 Go 语言中常见的同步原语 sync.Mutex、sync.RWMutex、sync.WaitGroup、sync.Once 和 sync.Cond 以及扩展原语 golang/sync/errgroup.Group、golang/sync/semaphore.Weighted 和 golang/sync/singleflight.Group 的实现原理，同时也会涉及互斥锁、信号量等并发编程中的常见概念。

2.2. 互斥锁（Mutex） #

2.2.1 正常模式和饥饿模式 #

sync.Mutex 有两种模式 — 正常模式和饥饿模式。我们需要在这里先了解正常模式和饥饿模式都是什么以及它们有什么样的关系。

在正常模式下，锁的等待者会按照先进先出的顺序获取锁。但是刚被唤起的 Goroutine 与新创建的 Goroutine 竞争时，大概率会获取不到锁，为了减少这种情况的出现，一旦 Goroutine 超过 1ms 没有获取到锁，它就会将当前互斥锁切换饥饿模式，防止部分 Goroutine 被『饿死』。

在饥饿模式中，互斥锁会直接交给等待队列最前面的 Goroutine。新的 Goroutine 在该状态下不能获取锁、也不会进入自旋状态，它们只会在队列的末尾等待。如果一个 Goroutine 获得了互斥锁并且它在队列的末尾或者它等待的时间少于 1ms，那么当前的互斥锁就会切换回正常模式。

2.2.2 加锁和解锁 #

如果互斥锁的状态不是 0 时就会调用 sync.Mutex.lockSlow 尝试通过自旋（Spinnig）等方式等待锁的释放，该方法的主体是一个非常大 for 循环，这里将它分成几个部分介绍获取锁的过程：

  1. 判断当前 Goroutine 能否进入自旋；
  2. 通过自旋等待互斥锁的释放；
  3. 计算互斥锁的最新状态；
  4. 更新互斥锁的状态并获取锁；

2.2.3 自旋的条件 #

Goroutine 进入自旋的条件非常苛刻：

  1. 互斥锁只有在普通模式才能进入自旋；
  2. runtime.sync_runtime_canSpin需要返回true：
    1. 运行在多 CPU 的机器上；
    2. 当前 Goroutine 为了获取该锁进入自旋的次数小于四次；
    3. 当前机器上至少存在一个正在运行的处理器 P 并且处理的运行队列为空；

一旦当前 Goroutine 能够进入自旋就会调用runtime.sync_runtime_doSpin和 runtime.procyield并执行 30 次的 PAUSE 指令，该指令只会占用 CPU 并消耗 CPU 时间：

2.3. 小结 #

我们已经从多个方面分析了互斥锁 sync.Mutex 的实现原理，这里我们从加锁和解锁两个方面总结注意事项。

互斥锁的加锁过程比较复杂，它涉及自旋、信号量以及调度等概念：

  • 如果互斥锁处于初始化状态，会通过置位 mutexLocked 加锁；
  • 如果互斥锁处于 mutexLocked 状态并且在普通模式下工作，会进入自旋，执行 30 次 PAUSE 指令消耗 CPU 时间等待锁的释放；
  • 如果当前 Goroutine 等待锁的时间超过了 1ms，互斥锁就会切换到饥饿模式；
  • 互斥锁在正常情况下会通过 runtime.sync_runtime_SemacquireMutex将尝试获取锁的 Goroutine 切换至休眠状态，等待锁的持有者唤醒；
  • 如果当前 Goroutine 是互斥锁上的最后一个等待的协程或者等待的时间小于 1ms，那么它会将互斥锁切换回正常模式；

互斥锁的解锁过程与之相比就比较简单，其代码行数不多、逻辑清晰，也比较容易理解：

  • 当互斥锁已经被解锁时，调用 sync.Mutex.Unlock会直接抛出异常；
  • 当互斥锁处于饥饿模式时，将锁的所有权交给队列中的下一个等待者，等待者会负责设置 mutexLocked 标志位；
  • 当互斥锁处于普通模式时，如果没有 Goroutine 等待锁的释放或者已经有被唤醒的 Goroutine 获得了锁，会直接返回；在其他情况下会通过 sync.runtime_Semrelease唤醒对应的 Goroutine；