Go-Mutex

十三Tech
104 阅读3分钟

Mutex的演进阶段

  • “初版”的 Mutex 使用一个 flag 来表示锁是否被持有，实现比较简单
  • 后来照顾到新来的 goroutine，所以会让新的 goroutine 也尽可能地先获取到锁，这是第二个阶段，“给新人机会”
  • 第三阶段“多给些机会”，照顾新来的和被唤醒的 goroutine；
  • 这样会带来饥饿问题，所以目前又加入了饥饿的解决方案，也就是第四阶段“解决饥饿”

image.png

补充概念： CAS 指令将给定的值和一个内存地址中的值进行比较，如果它们是同一个值，就使用新值替换内存地址中的值，这个操作是原子性的

初版的互斥锁

type Mutex struct { 
    key  int32 // 锁是否被持有的标识 
    sema int32 // 信号量专用，用以阻塞/唤醒goroutine 
}

image.png

调用 Lock 请求锁的时候，通过 xadd 方法进行 CAS 操作，xadd 方法通过循环执行 CAS 操作直到成功，保证对 key 加 1 的操作成功完成。如果比较幸运，锁没有被别的 goroutine 持有，那么，Lock 方法成功地将 key 设置为 1，这个 goroutine 就持有了这个锁；如果锁已经被别的 goroutine 持有了，那么，当前的 goroutine 会把 key 加 1，而且还会调用 semacquire 方法，使用信号量将自己休眠，等锁释放的时候，信号量会将它唤醒。

持有锁的 goroutine 调用 Unlock 释放锁时，它会将 key 减 1。如果当前没有其它等待这个锁的 goroutine，这个方法就返回了。但是，如果还有等待此锁的其它 goroutine，那么，它会调用 semrelease 方法，利用信号量唤醒等待锁的其它 goroutine 中的一个

初版的 Mutex 实现有一个问题：请求锁的 goroutine 会排队等待获取互斥锁。虽然这貌似很公平，但是从性能上来看，却不是最优的。因为如果我们能够把锁交给正在占用 CPU 时间片的 goroutine 的话，那就不需要做上下文的切换，在高并发的情况下，可能会有更好的性能

给新人机会

type Mutex struct { 
    state int32 
    sema uint32 
} 

const ( 
    mutexLocked = 1 << iota // mutex is locked 
    mutexWoken 
    mutexWaiterShift = iota 
)

Mutex 结构体还是包含两个字段，但是第一个字段已经改成了 state image.png

state 是一个复合型的字段，一个字段包含多个意义，这样可以通过尽可能少的内存来实现互斥锁

这个字段的第一位（最小的一位）来表示这个锁是否被持有，第二位代表是否有唤醒的 goroutine，剩余的位数代表的是等待此锁的 goroutine 数

相对于初版的设计，这次的改动主要就是，新来的 goroutine 也有机会先获取到锁，甚至一个 goroutine 可能连续获取到锁，打破了先来先得的逻辑。但是，代码复杂度也显而易见

多给些机会

如果新来的 goroutine 或者是被唤醒的 goroutine 首次获取不到锁，它们就会通过自旋（spin，通过循环不断尝试，spin 的逻辑是在runtime 实现的）的方式，尝试检查锁是否被释放。在尝试一定的自旋次数后，再执行原来的逻辑

解决机会

在极端情况下，等待中的 goroutine 可能会一直获取不到锁，这就是饥饿问题 Go1.9之后的state字段

image.png

饥饿模式的最大等待时间阈值设置成了 1 毫秒，一旦等待者等待的时间超过了这个阈值，Mutex 的处理就有可能进入饥饿模式，优先让等待者先获取到锁

avatar
文章
阅读
粉丝