Go: 关于锁的1234

最新推荐文章于 2023-08-30 17:51:59 发布

felix021

最新推荐文章于 2023-08-30 17:51:59 发布

阅读量298

点赞数

文章标签：内核多线程 java 编程语言并发编程

本文链接：https://blog.csdn.net/felix021/article/details/107588011

版权

在上一篇《踩坑记：Go服务灵异panic》里我们提到了 mutex 和 atomic ，感觉意犹未尽，这篇再展开一点。

- 锁 -

前面我们讲过好多面试题了，其实锁也很适合用来做套题，比如可以这么切入：sync.Mutex 是悲观锁还是乐观锁？

有些候选人不了解它们的区别，回答靠猜，缺乏逻辑以至于我都记不住。虽然这只是一个概念性的知识，但是却很能反映候选人的工作经验，比如读多写少的并发场景，乐观锁可以减少加锁冲突带来的开销。

当然大多数人还是知道的，于是可以继续问：你有了解过锁是怎么实现的吗？

很多人都能想到：维护一个初值为 false 的变量，当一个线程加锁成功的时候，将它置为 true ，就可以保证其他线程无法再获取。

逻辑是没错，但真正的问题是：两个线程同时检查，发现它的值都是 false ，如何保证只有一个线程会把它置为 true 呢？

这样的提问让不少候选人意识到，自己其实并没有真正理解锁。

- 原子操作 -

学过操作系统原理的同学应该都知道，靠的是原子操作（atomic operations）。

那么具体是什么原子操作呢？

在早期只有单核的系统上只需要关闭中断就可以保证原子地执行一段代码 —— 但这通常效率较低，且还存在些问题，例如因为 bug 或恶意代码导致未能正常开启中断，系统就会锁死；而对于多核系统，通常也无法做到在多个核心上同时关闭中断。

因此 CPU 引入了硬件支持的原子操作，例如 x86 体系下的 LOCK 信号（在汇编里给指令加上 LOCK 前缀），通过锁定总线，禁止其他 CPU 对内存的操作来保证原子性。但这样的锁粒度太粗，其他无关的内存操作也会被阻塞，大幅降低系统性能，而随着核数逐渐增加该问题会愈发显著 —— 要知道现在连家用 CPU 都有16核了。

因此 Intel 在 Pentium 486 开始引入了用于保证缓存一致性的 MESI 协议，通过锁定对应的 cache line，使得其他 core 无法修改指定内存，从而实现了原子操作（缓存锁）。这里不展开了，对细节感兴趣的话，详见参考资料《原子操作是如何实现的》[1]。

- CAS -

针对前面问的“什么原子操作”，大多数候选人的回答是 CAS （compare-and-swap），也有人会提到 test-and-set 等其他操作，原理都一样，就是用前述机制实现的。

下面这段 Go 代码展示了 CAS 的逻辑：

func CompareAndSwap(p *int, oldValue int, newValue int) bool {
  if *p != oldValue {
    return false
  }
  *p = newValue
  return true
}

请注意：这不是 CAS 的实现，如前所述，真正的 CAS 是硬件级别的指令支持的，最早出现在 1970 年 IBM 的 System 370 上，在 x86 上则是 80486 开始新增的 CMPXCHG 这个指令。

注：在多核系统上 CMPXCHG 也需要使用 LOCK 前缀，但是如果对应内存已经在 cache 里，就不用发出 LOCK 信号锁定总线，而是使用缓存锁。

由于不用锁定总线，这样的原子操作指令不会限制其余 CPU core 操作非锁定内存，因此对系统整体的吞吐量影响不大。这一点对于当今核数越来越多的系统来说尤为重要。

由于原子操作指令仍然需要在 CPU 之间传递消息用于对 cache line 的锁定，其性能仍有一定损耗，具体来说大概就相当于一个未命中 cache 的 Load Memory 指令[2]。

基于 CAS 我们可以用实现很多实用的原子操作，例如原子加法：

func atomicAdd(p *int32, incr int32) int32 {
  for {
    oldValue := *p
    newValue := oldValue + incr
    if atomic.CompareAndSwapInt32(p, oldValue, newValue) {
      return newValue
    }
  }
}

看，这就是一个典型的使用乐观锁的实现了：先做加法，如果更新失败，就换个姿势再来一次。

注：Go 语言 atomic.AddInt32 的实现是直接使用汇编 LOCK XADDL 完成的，不是基于 CAS 和循环。

- 自旋锁 -

回到锁的问题上，基于 CAS 我们可以很容易实现一个锁：

type spinLock int32
func (p *spinLock) Lock() {
  for !atomic.CompareAndSwapInt32((*int32)(p), 0, 1) {
  }
}
func (p *spinLock) Unlock() {
  atomic.StoreInt32((*int32)(p), 0)
}

这就是经典的自旋锁[3] —— 通过反复检测锁变量是否可用来完成加锁。在加锁过程中 CPU 是在忙等待，因此仅适用于阻塞较短时间的场合；其优势在于避免了线程切换的开销。

注：spinlock 是 Linux 内核中主要的两种锁之一（另一种是Mutex），感兴趣的同学可以去看看内核源码里的实现，具体位于 include/asm/spinlock.h （吐槽：内核源码真是难读）。

在 Go 版的实现里还要注意：如果 GOMAXPROCS 被设置成 1 （Go Runtime只会给用户代码分配一个系统线程），会导致上述代码陷入死循环，因此更完善的实现是：

func (p *spinLock) Lock() {
  for !atomic.CompareAndSwapInt32((*int32)(p), 0, 1) {
    runtime.Gosched()
  }
}

通过将当前系统线程的使用权暂时归还给 Go Runtime（相当于其他语言的 yield），可以避免前述情况，但这也在一定程度上破坏了自旋锁的语义、使其变得更重了。

值得一提的是，研究人员发现，如果锁冲突比较频繁，在 CAS 失败时使用指数退避算法（Exponential Backoff）往往能得到更好的整体性能[2]。

- Mutex -

实际上 Go 语言没有提供自带的自旋锁实现，我们在代码中用得更多的是 Mutex 。

对比于 Spinlock 的忙等待，如果 Mutex 未获得锁，会释放对 CPU 的占用。

上一篇我们在说 Mutex 性能不够好的时候有提到“lock does not scale with the number of the processors”，这里的 lock 指的是用 CPU LOCK信号实现的锁；而通过阅读 Mutex 的源码，我发现实际上 Mutex 底层也是使用原子操作来实现的，所以前述说法不太准确。

Mutex 针对实际应用场景做了许多优化，是一个从轻量级锁逐渐升级到重量级锁的过程，从而平衡了各种场景下的需求和性能。

具体来说有这么几项：