这是帖子的摘录；完整的帖子可以在这里找到：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 位整数，显示互斥体的当前状态。它实际上被分为多个位，对有关互斥体的各种信息进行编码。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
让我们从图像中总结一下状态：
- 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：正常和饥饿模式。
