Go Sync Mutex：正常模式和饥饿模式

从现在开始，努力学习吧！本文《Go Sync Mutex：正常模式和饥饿模式》主要讲解了等等相关知识点，我会在golang学习网中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！

这是帖子的摘录；完整的帖子可以在这里找到：golang sync mutex：正常和饥饿模式。

互斥体，或 mut双 ex包含，在 go 中基本上是一种确保一次只有一个 goroutine 干扰共享资源的方法。该资源可以是一段代码、一个整数、一个映射、一个结构、一个通道或几乎任何东西。

现在，上面的解释并不是严格的“学术”定义，但它是理解这个概念的有用方法。

在今天的讨论中，我们仍然从问题出发，转向解决方案，然后深入探讨它实际上是如何组合在一起的。

为什么我们需要sync.mutex？

如果你花了足够的时间在 go 中摆弄地图，你可能会遇到像这样的令人讨厌的错误：

fatal error: concurrent map read and map write

发生这种情况是因为我们没有保护我们的映射免受多个 goroutine 试图同时访问和写入的影响。

现在，我们可以使用带有互斥锁或sync.map的映射，但这不是我们今天的重点。这里的明星是sync.mutex，它有三个主要操作：lock、unlock 和 trylock（我们现在不会讨论）。

当一个 goroutine 锁定一个互斥锁时，它基本上是在说，“嘿，我要使用一下这个共享资源”，并且所有其他 goroutine 都必须等待直到互斥锁被解锁。一旦完成，它应该解锁互斥体，以便其他 goroutine 可以轮到他们。

就这么简单，让我们通过一个简单的反例来看看它是如何工作的：

var counter = 0
var wg sync.waitgroup

func incrementcounter() {
    counter++
    wg.done()
}

func main() {
    for i := 0; i < 1000; i++ {
        wg.add(1)
        go incrementcounter()
    }

    wg.wait()
    fmt.println(counter)
}

所以，我们有了这个在 1000 个 goroutine 之间共享的计数器变量。 go 新手可能会认为结果应该是 1000，但事实并非如此。这是因为所谓的“竞争条件”。

当多个 goroutine 尝试在没有适当同步的情况下同时访问和更改共享数据时，就会发生竞争情况。在这种情况下，增量操作 (counter++) 不是原子的。

由多个步骤组成，下面是 arm64 架构下 counter++ 的 go 汇编代码：

movd    main.counter(sb), r0
add $1, r0, r0
movd    r0, main.counter(sb)

counter++ 是一个读取-修改-写入操作，上面的这些步骤不是原子的，这意味着它们不是作为单个、不间断的操作执行的。

例如，goroutine g1 读取 counter 的值，在写入更新值之前，goroutine g2 读取相同的值。然后两者都将更新后的值写回，但由于它们读取的是相同的原始值，因此实际上丢失了一个增量。

使用atomic包是解决这个问题的好方法，但今天让我们重点讨论互斥体如何解决这个问题：

var counter = 0
var wg sync.waitgroup
var mutex sync.mutex

func incrementcounter() {
    mutex.lock()
    counter++
    mutex.unlock()
    wg.done()
}

func main() {
    for i := 0; i < 1000; i++ {
        wg.add(1)
        go incrementcounter()
    }

    wg.wait()
    fmt.println(counter)
}

现在，结果是 1000，正如我们预期的那样。在这里使用互斥锁非常简单：用 lock 和 unlock 包装关键部分。但要小心，如果你在一个已经解锁的互斥体上调用 unlock，将会导致致命错误同步：解锁已解锁的互斥体。

通常最好使用 defer mutex.unlock() 来确保解锁发生，即使出现问题也是如此。我们还有一篇关于 golang defer：从基础到陷阱的文章。

另外，你可以通过运行runtime.gomaxprocs(1)将gomaxprocs设置为1，结果在1000时仍然是正确的。这是因为我们的goroutines不会并行运行，而且函数足够简单运行时被抢占。

互斥体结构：剖析

在我们深入了解 go 的sync.mutex 中的锁定和解锁流程如何工作之前，让我们先分解一下互斥体本身的结构或解剖结构：

package sync

type mutex struct {
    state int32
    sema  uint32
}

go 中的互斥锁的核心有两个字段：state 和 sema。它们可能看起来像简单的数字，但它们的内涵远不止表面上看到的那样。

状态字段是一个 32 位整数，显示互斥体的当前状态。它实际上被分为多个位，对有关互斥体的各种信息进行编码。

让我们从图像中总结一下状态：

• locked（位0）：互斥锁当前是否被锁定。如果设置为 1，则互斥体被锁定，其他 goroutine 无法获取它。
• woken（位 1）：如果任何 goroutine 已被唤醒并尝试获取互斥锁，则设置为 1。其他 goroutine 不应在不必要的情况下被唤醒。
• 饥饿（位 2）：该位显示互斥锁是否处于饥饿模式（设置为 1）。我们稍后将深入探讨此模式的含义。
• waiter（位 3-31）：其余位跟踪有多少 goroutines 正在等待互斥体。

另一个字段 sema 是一个 uint32，充当信号量来管理等待的 goroutine 并发出信号。当互斥锁被解锁时，等待的 goroutine 之一被唤醒以获取锁。

与状态字段不同，sema 没有特定的位布局，而是依赖运行时内部代码来处理信号量逻辑。

互斥锁流程

在mutex.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()
}

快速路径被设计得非常快，并且预计可以处理大多数尚未使用互斥体的锁定获取。该路径也是内联的，这意味着它直接嵌入到调用函数中：

$ go build -gcflags="-m"

./main.go:13:12: inlining call to sync.(*mutex).lock
./main.go:15:14: inlining call to sync.(*mutex).unlock

仅供参考，这个内联快速路径是一个巧妙的技巧，利用了 go 的内联优化，并且在 go 的源代码中被大量使用。

当快速路径中的 cas（比较和交换）操作失败时，这意味着状态字段不为 0，因此互斥体当前被锁定。

这里真正关心的是慢速路径 m.lockslow，它完成了大部分繁重的工作。我们不会太深入地研究源代码，因为它需要大量有关 go 内部工作原理的知识。

我将讨论该机制，也许还有一些内部代码，以使事情变得清晰。在慢速路径中，goroutine 不断主动旋转以尝试获取锁，它不会直接进入等待队列。

“旋转是什么意思？”

自旋意味着 goroutine 进入紧密循环，在不放弃 cpu 的情况下反复检查互斥体的状态。

在这种情况下，它不是一个简单的 for 循环，而是执行旋转等待的低级汇编指令。让我们快速浏览一下 arm64 架构上的这段代码：

TEXT runtime·procyield(SB),NOSPLIT,$0-0
    MOVWU   cycles+0(FP), R0
again:
    YIELD
    SUBW    $1, R0
    CBNZ    R0, again
    RET

汇编代码运行 30 个周期的紧密循环 (runtime.procyield(30))，反复让出 cpu 并递减旋转计数器。

自旋后，它会尝试再次获取锁。如果失败，在放弃之前还有三次旋转的机会。因此，总共会尝试最多 120 个周期。如果仍然无法获得锁，则会增加等待者计数，将自己放入等待队列，进入睡眠状态，等待信号唤醒并重试。

为什么我们需要旋转？

旋转背后的想法是等待一小会儿，希望互斥体很快就会释放，让 goroutine 抓住互斥体，而无需睡眠-唤醒周期的开销。

...

完整帖子可在此处查看：go sync mutex：正常和饥饿模式。

终于介绍完啦！小伙伴们，这篇关于《Go Sync Mutex：正常模式和饥饿模式》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！