Go 中的 Mutex 设计原理详解（三）

Mutex系列是根据我对晁岳攀老师的《Go 并发编程实战课》的吸收和理解整理而成，如有偏差，欢迎指正~

Mutex 演变回顾

在前面两篇文章中，分别介绍了初版 Mutex 和 第二版 Mutex (给新人机会) 。

初版 Mutex 的核心思想用先来后到的方式解决锁的竞争问题。具体表现是用一个标志 key 来记录锁是否被占有，以及处于等待中的协程有多少个。等占有锁的协程完成任务后，按等待顺序唤醒下一个协程。表面上看，这样处理很公平，但是公平不能当饭吃，尤其是在高并发的场景下性能会比较低。性能较低的原因可以看上一篇。

第二版 Mutex，为了解决这个问题，提出的方案是给新人机会。即被唤醒的协程不能立即拥有锁，而是需要和新来的协程一起竞争锁，这样新来的协程也能有机会占有锁。好处就是新来协程都是正占用着 CPU 的时间片，执行任务更快，整体性能消耗小。

新的问题

新的问题基于这样一个事实：大多数时候，协程在独占锁的期间，对数据进行的操作其实耗时很小，比唤醒操作的消耗还小。被唤醒的协程没有抢到锁立刻就沉睡，然后下次还要被再次唤醒，整体上性能是有些浪费的。

面对这种问题，Go 的解决方案是：多给些机会（自旋）。

第三版 Mutex: 多给些机会

第三版的 Mutex 的结构体的定义和第二版没有任何区别，所以我们直接看加锁和解锁的实现。

新的加锁：Lock

还是直接上源码

// Lock locks m.
// If the lock is already in use, the calling goroutine
// blocks until the mutex is available.
func (m *Mutex) Lock