sync.Mutex是Go实现的互斥锁，提供了基本的同步操作，使用很方便。
不过，你是否好奇过，Go是如何实现的Mutex，又是为什么要这样实现？
今天跟随几个问题，我们一起探索下Mutex背后的设计。
（不用担心，不会有大段的源码分析出现在本文 ????）
文章目录
0x01 为什么需要锁
非原子操作
内存重排
0x02 mutex 如何实现原子操作
0x03 mutex 如何避免内存重排
0x04 Go 对 mutex 的优化点
不一直让 cpu 空转等待锁
用信号量实现睡眠的协程唤起
避免过多无效的协程唤起
锁当然是为了保证同步操作，或者应该这样问：没有锁的时候，为什么会有不同步？
这里导致不同步的原因主要有两点：
如果一个线程的内存操作的中间状态（比如只完成一半），可以被另一个线程获取到，那么其操作就是非原子操作。
或者说其操作不是不可再分的。
比如自增操作i++, i的读取、修改、写入（RMW），其底层cpu 和内存实际交互了两次，自然没法保证操作过程的原子性。
自增操作那直接读取操作是否就能保证原子性呢？
也不一定，比如一般操作系统操作内存的最小粒度是一个机器字machine word(32 位系统是4B,64 位系统是8B)
内存对齐的情况下，在 32 位系统上读取一个int64(8B)就不可能是原子的，更别说如果内存是不对齐的了。
我们写的代码顺序与实际执行的顺序可能并不一致。这是因为有内存重排的存在。他会发生在两个地方：
语言编译时
语言为了一些优化考虑，可能会在编译期间重排代码顺序。
系统执行时
这个完全取决于系统底层指令的实现，主要是为了更好利用那些原本要浪费掉的指令周期，提升程序的执行速度。
比如 cpu 和主存（main memory）访问延时是很高的。多核时代，每个 cpu 核为了加速访问，就增加了各自与主存交互的缓存(cache)。
如果缓存中有就无需再和主存交互了。如下图所示：
cpu的缓存与主存但有多份缓存，就需要有缓存一致（cache coherency）协议保证他们的结果一致。(具体可以了解MESI 协议[1])。
这种情况下，如果多个 cpu 核同时修改或读取同一份数据，且这份数据在各自的缓存中，为避免缓存间不一致，就不可避免有的 cpu 核要等待其他 cpu 核先操作数据。
所以在这些 cpu 核等待期间，他可以先执行其他内存指令。
详细可以参考 Understanding memory reordering[2] 这篇文章。
利用atomic提供的AddInt32和CompareAndSwapInt32函数，其底层使用了系统架构提供的LOCK前缀指令。
该指令会设置处理器的LOCK信号。
这个信号会使总线锁定，阻止其他处理器接管总线访问内存，直到使用LOCK前缀指令执行结束，这会使这条指令的执行变为原子操作。
在多处理器环境下，设置LOCK信号能保证某个处理器对共享内存的独占使用。
具体指令参见：runtime/internal/atomic/asm_amd64.s
如Cas的实现如下：
// bool Cas(int32 *val, int32 old, int32 new) // Atomically: // if(*val == old){ // *val = new; // return 1; // } else // return 0; TEXT runtime∕internal∕atomic·Cas(SB),NOSPLIT,$0-17 MOVQ ptr+0(FP), BX MOVL old+8(FP), AX MOVL new+12(FP), CX LOCK CMPXCHGL CX, 0(BX) SETEQ ret+16(FP) RET上边提到的LOCK指令及XCHG等指令，会引入内存屏障（memory barrier）
内存屏障是强制处理器按照可预知的方式访问内存的 CPU 指令。
内存屏障的工作方式类似路障：内存屏障之前的指令保证先于内存屏障之后的指令执行。
更多关于内存屏障可以看看这篇文章中对 POSIX 多线程程序设计-3.4 节[3] 引用。
有了底层架构指令支持，如果Go直接基于atomic.CAS+cpu 时钟周期阻塞，就可实现常见的自旋锁（spinLock）：
未获取锁前阻塞线程，每次等待一些 cpu 时钟周期，直到锁可用就好了。
但 Go 自己还是做了一些优化，一般情况下会优于常见的多线程互斥锁。
主要优化点是：
一直自旋最大的问题就是浪费 cpu 时钟周期，会占用一些 cpu，除非锁能很快获取到的。
所以 Go 在多核且不会影响其他Goroutine调度时，会最多自旋 4 次，且每次空转 30 个 cpu 时钟周期。以期能短期内获取锁。
详见runtime_canSpin和runtime_doSpin (源码见runtime/proc.go)
上边说了不会一直空转 cpu，那 4 次空转之后锁还没好，怎么办？
在多线程场景里一般就会基于信号量（semaphore）实现 futex[4]，来让线程睡眠直至条件满足后唤醒。
Go 也用信号量实现了类似futex的wake和sleep. 只不过他们管理的 Go 自己调度的协程而非线程。
这样好处是，让协程等待的代价要比线程更低，而且协程上下文切换也更快一些。
如果一个锁有多个协程在抢，且已经有被挂起的协程在等待唤起。
这种情况下，当锁释放，等待被唤起的协程被唤醒时，他会和其他已经在 cpu 上运行的协程一起去抢锁，自然很容易失败而导致继续挂起。
为缓解这种极端情况的延迟。Go增加饥饿模式（starvation mode）：
正常情况按先进先出唤醒抢锁；如果有协程获取锁失败被挂起超过1ms，就将其放到队首，并转为饥饿模式。
这种模式下，下次唤醒就直接把锁交给（handoff）队首等待已久的协程。
了解这些，再去看mutex的源码可能会更好理解一些。
最后推荐一个 Talk，是英文版的，里边有很详细的关于mutex的讨论。
2019 - Kavya Joshi - Let
[1]
MESI协议: https://zh.wikipedia.org/wiki/MESI%E5%8D%8F%E8%AE%AE
[2]
Understanding memory reordering: https://www.internalpointers.com/post/understanding-memory-ordering
[3]
POSIX多线程程序设计-3.4节: https://my.oschina.net/chuqq/blog/3022854
[4]
futex: https://zh.wikipedia.org/wiki/Futex
如果有用，点个 在看 ，让更多人看到
外链不能跳转，戳 阅读原文 查看参考资料
