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() {
// Fast path: grab unlocked mutex.