这可能是最容易理解的 Go Mutex 源码剖析

Hi，大家好，我是 haohongfan。

上一篇文章《一文完全掌握 Go math/rand》，我们知道 math/rand 的 global rand 有一个全局锁，我的文章里面有一句话：“修复方案: 就是把 rrRand 换成了 globalRand, 在线上高并发场景下, 发现全局锁影响并不大.”，有同学私聊我“他们遇到线上服务的锁竞争特别激烈”。确实我这句话说的并不严谨。但是也让我有了一个思考：到底多高的 QPS 才能让 Mutex 产生强烈的锁竞争？

到底加锁的代码会不会产生线上问题？到底该不该使用锁来实现这个功能？线上的问题是不是由于使用了锁造成的？针对这些问题，本文就从源码角度剖析 Go Mutex, 揭开 Mutex 的迷雾。

源码分析

Go mutex 源码只有短短的 228 行，但是却包含了很多的状态转变在里面，很不容易看懂，具体可以参见下面的流程图。Mutex 的实现主要借助了 CAS 指令 + 自旋 + 信号量来实现，具体代码我就不再每一行做分析了，有兴趣的可以根据下面流程图配合源码阅读一番。

Lock

Unlock

一些例子

1. 一个 goroutine 加锁解锁过程

2. 没有加锁，直接解锁问题

3. 两个 Goroutine，互相加锁解锁

4. 三个 Goroutine 等待加锁过程

整篇源码其实涉及比较难以理解的就是 Mutex 状态（mutexLocked，mutexWoken，mutexStarving，mutexWaiterShift）与 Goroutine 之间的状态（starving，awoke）改变，我们下面将逐一说明。

什么是 Goroutine 排队?

如果 Mutex 已经被一个 Goroutine 获取了锁, 其它等待中的 Goroutine 们只能一直等待。那么等这个锁释放后，等待中的 Goroutine 中哪一个会优先获取 Mutex 呢?

正常情况下, 当一个 Goroutine 获取到锁后, 其他的 Goroutine 开始进入自旋转(为了持有CPU) 或者进入沉睡阻塞状态(等待信号量唤醒). 但是这里存在一个问题, 新请求的 Goroutine 进入自旋时是仍然拥有 CPU 的, 所以比等待信号量唤醒的 Goroutine 更容易获取锁. 用官方话说就是，新请求锁的 Goroutine具有优势，它正在CPU上执行，而且可能有好几个，所以刚刚唤醒的 Goroutine 有很大可能在锁竞争中失败.

于是如果一个 Goroutine 被唤醒过后, 仍然没有拿到锁, 那么该 Goroutine 会放在等待队列的最前面. 并且那些等待超过 1 ms 的 Goroutine 还没有获取到锁，该 Goroutine 就会进入饥饿状态。该 Goroutine 是饥饿状态并且 Mutex 是 Locked 状态时，才有可能给 Mutex 设置成饥饿状态.

获取到锁的 Goroutine Unlock, 将 Mutex 的 Locked 状态解除, 发出来解锁信号, 等待的 Goroutine 开始竞争该信号. 如果发现当前 Mutex 是饥饿状态, 直接将唤醒信号发给第一个等待的 Goroutine

这就是所谓的 Goroutine 排队

排队功能是如何实现的

我们知道在正常状态下，所有等待锁的 Goroutine 按照 FIFO 顺序等待，在 Mutex 饥饿状态下，会直接把释放锁信号发给等待队列中的第一个Goroutine。排队功能主要是通过 runtime_SemacquireMutex, runtime_Semrelease 来实现的.

1. runtime_SemacquireMutex -- 入队

当 Mutex 被其他 Goroutine 持有时，新来的 Goroutine 将会被 runtime_SemacquireMutex 阻塞。阻塞会分为2种情况:

Goroutine 第一次被阻塞：

当 Goroutine 第一次尝试获取锁时，由于当前锁可能不能被锁定，于是有可能进入下面逻辑

queueLifo := waitStartTime != 0

if waitStartTime == 0 {

    waitStartTime = runtime_nanotime()

}

runtime_SemacquireMutex(&m.sema, queueLifo, 1)

由于 waitStartTime 等于 0，runtime_SemacquireMutex 的 queueLifo 等于 false, 于是该 Goroutine 放入到队列的尾部。

Goroutine 被唤醒过，但是没加锁成功，再次被阻塞

由于 Goroutine 被唤醒过，waitStartTime 不等于 0，runtime_SemacquireMutex 的 queueLifo 等于 true, 于是该 Goroutine 放入到队列的头部。

2. runtime_Semrelease -- 出队

当某个 Goroutine 释放锁时，调用 Unlock，这里同样存在两种情况：

当前 mutex 不是饥饿状态

if new&mutexStarving == 0 {

    old := new

    for {

        if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken|mutexStarving) != 0 {

            return

        }

        // Grab the right to wake someone.

        new = (old - 1<<mutexWaiterShift) | mutexWoken

        if atomic.CompareAndSwapInt32(&m.state, old, new) {

            runtime_Semrelease(&m.sema, false, 1)

            return

        }

        old = m.state

    }

}

Unlock 时 Mutex 的 Locked 状态被去掉。当发现当前 Mutex 不是饥饿状态，设置 runtime_Semrelease 的 handoff 参数是 false, 于是唤醒其中一个 Goroutine。

当前 mutex 已经是饥饿状态

} else {

    // Starving mode: handoff mutex ownership to the next waiter, and yield

    // our time slice so that the next waiter can start to run immediately.

    // Note: mutexLocked is not set, the waiter will set it after wakeup.

    // But mutex is still considered locked if mutexStarving is set,

    // so new coming goroutines won't acquire it.

    runtime_Semrelease(&m.sema, true, 1)

}

同样 Unlock 时 Mutex 的 Locked 状态被去掉。由于当前 Mutex 是饥饿状态，于是设置 runtime_Semrelease 的 handoff 参数是 true, 于是让等待队列头部的第一个 Goroutine 获得锁。

Goroutine 的排队与 mutex 中记录的 Waiters 之间的关系?

通过上面的分析，我们知道 Goroutine 的排队是通过 runtime_SemacquireMutex 来实现的。Mutex.state 记录了目前通过 runtime_SemacquireMutex 排队的 Goroutine 的数量

Goroutine 的饥饿与 Mutex 饥饿之间的关系？

Goroutine 的状态跟 Mutex 的是息息相关的。只有在 Goroutine 是饥饿状态下，才有可能给 Mutex 设置成饥饿状态。在 Mutex 是饥饿状态时，才有可能让饥饿的 Goroutine 优先获取到锁。不过需要注意的是，触发 Mutex 饥饿的 Goroutine 并不一定获取锁，有可能被其他的饥饿的 Goroutine 截胡。

Goroutine 能够加锁成功的情况

Mutex 没有被 Goroutine 占用 Mutex.state = 0, 这种情况下一定能获取到锁. 例如: 第一个 Goroutine 获取到锁

还有一种情况 Goroutine有可能加锁成功:

当前 Mutex 不是饥饿状态, 也不是 Locked 状态, 尝试 CAS 加锁时, Mutex 的值还没有被其他 Goroutine 改变, 当前 Goroutine 才能加锁成功.
某个 Goroutine 刚好被唤醒后, 重新获取 Mutex, 这个时候 Mutex 处于饥饿状态. 因为这个时候只唤醒了饥饿的 Goroutine, 其他的 Goroutine 都在排队中, 没有其他 Goroutine 来竞争 Mutex, 所以能直接加锁成功

Mutex 锁竞争的相关问题

探测锁竞争

日常开发中锁竞争的问题还是能经常遇到的，我们如何去发现锁竞争呢？其实还是需要靠 pprof 来人肉来分析。

《一次错误使用 go-cache 导致出现的线上问题》就是我真是遇到的一次线上问题，表象就是接口大量超时，打开pprof 发现大量 Goroutine 都集中 Lock 上。这个真实场景的具体的分析过程，有兴趣的可以阅读一下。

简单总结一下：

压测或者流量高的时候发现系统不正常，打开 pprof 发现 goroutine 指标在飙升，并且大量 Goroutine 都阻塞在 Mutex 的 Lock 上，这个基本就可以确定是锁竞争。

pprof 里面是有个 pprof/mutex 指标，不过该指标默认是关闭的，而且并没有太多资料有介绍这个指标如何来分析 Mutex。有知道这个指标怎么用的大佬，欢迎留言。

mutex 锁的瓶颈

现在模拟业务开发中的某接口，平均耗时 10 ms, 在 32C 物理机上压测。CentOS Linux release 7.3.1611 (Core), go1.15.8

压测代码如下：

package main

import (

	"fmt"

	"log"

	"net/http"

	"sync"

	"time"

	_ "net/http/pprof"

)

var mux sync.Mutex

func testMutex(w http.ResponseWriter, r *http.Request) {

	mux.Lock()

	time.Sleep(10 * time.Millisecond)

	mux.Unlock()

}

func main() {

	go func() {

		log.Println(http.ListenAndServe(":6060", nil))

	}()

	http.HandleFunc("/test/mutex", testMutex)

	if err := http.ListenAndServe(":8000", nil); err != nil {

		fmt.Println("start http server fail:", err)

	}

}

这个例子写的比较极端了，全局共享一个 Mutex。经过压测发现在 100 qps 时，Mutex 没啥竞争，在 150 QPS 时竞争就开始变的激烈了。

当然我们写业务代码并不会这么写，但是可以通过这个例子发现 Mutex 在 QPS 很低的时候，锁竞争就会很激烈。需要说明的一点：这个压测是数值没啥具体的意义，不同的机器上表现肯定还会不一样。

这个例子告诉我们几点：

写业务时不能全局使用同一个 Mutex
尽量避免使用 Mutex，如果非使用不可，尽量多声明一些 Mutex，采用取模分片的方式去使用其中一个 Mutex

日常使用注意点

1. Lock/Unlock 成对出现

我们日常开发中使用 Mutex 一定要记得：先 Lock 再 Unlock。

特别要注意的是：没有 Lock 就去 Unlock。当然这个 case 一般情况下我们都不会这么写。不过有些变种的写法我们要尤其注意，例如

var mu sync.Mutex

func release() {

	mu.Lock()

    fmt.Println("lock1 success")

	time.Sleep(10 * time.Second)

	mu.Lock()

	fmt.Println("lock2 success")

}

func main() {

	go release()

	time.Sleep(time.Second)

	mu.Unlock()

	fmt.Println("unlock success")

	for {}

}

输出结果：

release lock1 success

main unlock success

release lock2 success

我们看到 release goroutine 的锁竟然被 main goroutine 给释放了，同时 release goroutine 又能重新获取到锁。

这段代码可能你想不到有啥问题，其实这个问题蛮严重的，想象一下你的代码中，本来是要加锁给用户加积分的，但是竟然被别的 goroutine 给解锁了，导致积分没有增加成功，同时解锁的时候还别的 Goroutine 的锁给 Unlock 了，互相加锁解锁，导致莫名其妙的问题。

所以一般情况下，要在本 Goroutine 中完成 Mutex 的 Lock&Unlock，千万不要将要加锁和解锁分到两个 Goroutine 中进行。如果你确实需要这么做，请抽支烟冷静一下，你真的是否需要这么做。

2. Mutex 千万不能被复制

我之前发过的《当 Go struct 遇上 Mutex》里面详细分析了不能被复制的原因，以及如何 Mutex 的最佳使用方式，建议没看过的同学去看一遍。我们还是举个例子说下为啥不能被复制，以及如何用源码进行分析

type Person struct {

	mux sync.Mutex

}

func Reduce(p1 Person) {

	fmt.Println("step...", )

	p1.mux.Lock()

	fmt.Println(p1)

	defer p1.mux.Unlock()

	fmt.Println("over...")

}

func main() {

	var p Person

	p.mux.Lock()

	go Reduce(p)

	p.mux.Unlock()

	fmt.Println(111)

	for {}

}

问题分析：

main Goroutine 已经给 p.mux 加了锁 , 这个时候 p.mux 的 state 的值是 mutexLocked。
然后将 p.mux 复制给了 Reduce Goroutine。这个时候被复制的 p1.mux 的 state 的值也是 mutexLocked。
main Goroutine 虽然已经解锁了, 但是 Reduce Goroutine 跟 main Goroutine 的 mutex 已经不是同一个 mutex 了, 所以 Reduce Goroutine 就会加锁失败, 产生死锁，关键是编译器还发现不了这个 Deadlock.

关于为什么编译器不能发现这个死锁，可以看我的博客《一次 Golang Deadlock 的讨论》

至此 Go Mutex 的源码剖析全部完毕了，有什么想跟我交流的可以再评论区留言。