专栏首页后端golang 系列: mutex 讲解
原创

golang 系列: mutex 讲解

摘要

Go 号称是为了高并发而生的,在高并发场景下,势必会涉及到对公共资源的竞争。当对应场景发生时,我们经常会使用 mutex 的 Lock()Unlock() 方法来占有或释放资源。虽然调用简单,但 mutex 的内部却涉及挺多的。今天,就让我们好好研究一下。

mutex 初步认识

mutex 的源码主要是在 src/sync/mutex.go文件里,它的结构体比较简单,如下:

type Mutex struct {
	state int32
	sema  uint32
}

我们可以看到有一个字段 sema,它表示信号量标记位。所谓的信号量是用于 Goroutine 之间阻塞或唤醒的。这有点像操作系统里的 PV 原语操作,我们先来认识下 PV 原语操作:

PV 原语解释:undefined通过操作信号量 S 来处理进程间的同步与互斥的问题。undefinedS>0:表示有 S 个资源可用;S=0 表示无资源可用;S<0 绝对值表示等待队列或链表中的进程个数。信号量 S 的初值应大于等于 0。undefinedP 原语:表示申请一个资源,对 S 原子性的减 1,若 减 1 后仍 S>=0,则该进程继续执行;若 减 1 后 S<0,表示已无资源可用,需要将自己阻塞起来,放到等待队列上。undefinedV 原语:表示释放一个资源,对 S 原子性的加 1;若 加 1 后 S>0,则该进程继续执行;若 加 1 后 S<=0,表示等待队列上有等待进程,需要将第一个等待的进程唤醒。

通过上面的解释,mutex 就可以利用信号量来实现 goroutine 的阻塞和唤起了。

其实 mutex 本质上就是一个关于信号量阻塞唤起操作。

当 goroutine 不能占有锁资源的时候会被阻塞挂起,此时不能继续执行后面的代码逻辑。

当 mutex 释放锁资源时,则会继续唤起之前的 goroutine 去抢占锁资源。

至于 mutex 的 state 状态字段则是用来做状态流转的,这些状态值涉及到了一些概念,下面我们具体来解释一番。

mutex 状态标志位

mutex 的 state 有 32 位,它的低 3 位分别表示 3 种状态:唤醒状态上锁状态饥饿状态,剩下的位数则表示当前阻塞等待的 goroutine 数量。

mutex 会根据当前的 state 状态来进入正常模式饥饿模式或者是自旋

mutex 正常模式

当 mutex 调用 Unlock() 方法释放锁资源时,如果发现有等待唤起的 Goroutine 队列时,则会将队头的 Goroutine 唤起。

队头的 goroutine 被唤起后,会调用 CAS 方法去尝试性的修改 state 状态,如果修改成功,则表示占有锁资源成功。

(注:CAS 在 Go 里用 atomic.CompareAndSwapInt32(addr *int32, old, new int32) 方法实现,CAS 类似于乐观锁作用,修改前会先判断地址值是否还是 old 值,只有还是 old 值,才会继续修改成 new 值,否则会返回 false 表示修改失败。)

mutex 饥饿模式

由于上面的 Goroutine 唤起后并不是直接的占用资源,还需要调用 CAS 方法去尝试性占有锁资源。如果此时有新来的 Goroutine,那么它也会调用 CAS 方法去尝试性的占有资源。

但对于 Go 的调度机制来讲,会比较偏向于 CPU 占有时间较短的 Goroutine 先运行,而这将造成一定的几率让新来的 Goroutine 一直获取到锁资源,此时队头的 Goroutine 将一直占用不到,导致饿死

针对这种情况,Go 采用了饥饿模式。即通过判断队头 Goroutine 在超过一定时间后还是得不到资源时,会在 Unlock 释放锁资源时,直接将锁资源交给队头 Goroutine,并且将当前状态改为饥饿模式

后面如果有新来的 Goroutine 发现是饥饿模式时, 则会直接添加到等待队列的队尾。

mutex 自旋

如果 Goroutine 占用锁资源的时间比较短,那么每次都调用信号量来阻塞唤起 goroutine,将会很浪费资源。

因此在符合一定条件后,mutex 会让当前的 Goroutine 去空转 CPU,在空转完后再次调用 CAS 方法去尝试性的占有锁资源,直到不满足自旋条件,则最终会加入到等待队列里。

自旋的条件如下:

  • 还没自旋超过 4 次
  • 多核处理器
  • GOMAXPROCS > 1
  • p 上本地 Goroutine 队列为空

可以看出,自旋条件还是比较严格的,毕竟这会消耗 CPU 的运算能力。

mutex 的 Lock() 过程

首先,如果 mutex 的 state = 0,即没有谁在占有资源,也没有阻塞等待唤起的 goroutine。则会调用 CAS 方法去尝试性占有锁,不做其他动作。

如果不符合 m.state = 0,则进一步判断是否需要自旋。

当不需要自旋又或者自旋后还是得不到资源时,此时会调用 runtime_SemacquireMutex 信号量函数,将当前的 goroutine 阻塞并加入等待唤起队列里。

当有锁资源释放,mutex 在唤起了队头的 goroutine 后,队头 goroutine 会尝试性的占有锁资源,而此时也有可能会和新到来的 goroutine 一起竞争。

当队头 goroutine 一直得不到资源时,则会进入饥饿模式,直接将锁资源交给队头 goroutine,让新来的 goroutine 阻塞并加入到等待队列的队尾里。

对于饥饿模式将会持续到没有阻塞等待唤起的 goroutine 队列时,才会解除。

Unlock 过程

mutex 的 Unlock() 则相对简单。同样的,会先进行快速的解锁,即没有等待唤起的 goroutine,则不需要继续做其他动作。

如果当前是正常模式,则简单的唤起队头 Goroutine。如果是饥饿模式,则会直接将锁交给队头 Goroutine,然后唤起队头 Goroutine,让它继续运行。

mutex 代码详解

好了,上面大体流程讲完了,下面将会把详细的代码流程呈上,让大家能更详细的知道 mutex 的 Lock()、Unlock() 方法逻辑。

mutex Lock() 代码详解:

// Lock mutex 的锁方法。
func (m *Mutex) Lock() {
	// 快速上锁.
	if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
		if race.Enabled {
			race.Acquire(unsafe.Pointer(m))
		}
		return
	}
	// 快速上锁失败,将进行操作较多的上锁动作。
	m.lockSlow()
}

func (m *Mutex) lockSlow() {
  var waitStartTime int64  // 记录当前 goroutine 的等待时间
  starving := false // 是否饥饿
  awoke := false // 是否被唤醒
  iter := 0 // 自旋次数
  old := m.state // 当前 mutex 的状态
  for {
    // 当前 mutex 的状态已上锁,并且非饥饿模式,并且符合自旋条件
    if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {
      // 当前还没设置过唤醒标识
      if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
        atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
        awoke = true
      }
      runtime_doSpin()
      iter++
      old = m.state
      continue
    }
    new := old
    // 如果不是饥饿状态,则尝试上锁
    // 如果是饥饿状态,则不会上锁,因为当前的 goroutine 将会被阻塞并添加到等待唤起队列的队尾
    if old&mutexStarving == 0 {
      new |= mutexLocked
    }
    // 等待队列数量 + 1
    if old&(mutexLocked|mutexStarving) != 0 {
      new += 1 << mutexWaiterShift
    }
    // 如果 goroutine 之前是饥饿模式,则此次也设置为饥饿模式
    if starving && old&mutexLocked != 0 {
      new |= mutexStarving
    }
    //
    if awoke {
      // 如果状态不符合预期,则报错
      if new&mutexWoken == 0 {
        throw("sync: inconsistent mutex state")
      }
      // 新状态值需要清除唤醒标识,因为当前 goroutine 将会上锁或者再次 sleep
      new &^= mutexWoken
    }
    // CAS 尝试性修改状态,修改成功则表示获取到锁资源
    if atomic.CompareAndSwapInt32(&m.state, old, new) {
      // 非饥饿模式,并且未获取过锁,则说明此次的获取锁是 ok 的,直接 return
      if old&(mutexLocked|mutexStarving) == 0 {
        break
      }
      // 根据等待时间计算 queueLifo
      queueLifo := waitStartTime != 0
      if waitStartTime == 0 {
        waitStartTime = runtime_nanotime()
      }
      // 到这里,表示未能上锁成功
      // queueLife = true, 将会把 goroutine 放到等待队列队头
      // queueLife = false, 将会把 goroutine 放到等待队列队尾
      runtime_SemacquireMutex(&m.sema, queueLifo, 1)
      // 计算是否符合饥饿模式,即等待时间是否超过一定的时间
      starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs
      old = m.state
      // 上一次是饥饿模式
      if old&mutexStarving != 0 {
        if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 {
          throw("sync: inconsistent mutex state")
        }
        delta := int32(mutexLocked - 1<<mutexWaiterShift)
        // 此次不是饥饿模式又或者下次没有要唤起等待队列的 goroutine 了
        if !starving || old>>mutexWaiterShift == 1 {
          delta -= mutexStarving
        }
        atomic.AddInt32(&m.state, delta)
        break
      }
      // 此处已不再是饥饿模式了,清除自旋次数,重新到 for 循环竞争锁。
      awoke = true
      iter = 0
    } else {
      old = m.state
    }
  }

  if race.Enabled {
    race.Acquire(unsafe.Pointer(m))
  }
}

mutex Unlock() 代码详解:

// Unlock 对 mutex 解锁.
// 如果没有上过锁,缺调用此方法解锁,将会抛出运行时错误。
// 它将允许在不同的 Goroutine 上进行上锁解锁
func (m *Mutex) Unlock() {
	if race.Enabled {
		_ = m.state
		race.Release(unsafe.Pointer(m))
	}

	// 快速尝试解锁
	new := atomic.AddInt32(&m.state, -mutexLocked)
	if new != 0 {
		// 快速解锁失败,将进行操作较多的解锁动作。
		m.unlockSlow(new)
	}
}

func (m *Mutex) unlockSlow(new int32) {
  // 非上锁状态,直接抛出异常
  if (new+mutexLocked)&mutexLocked == 0 {
    throw("sync: unlock of unlocked mutex")
  }
  // 正常模式
  if new&mutexStarving == 0 {
    old := new
    for {
      // 没有需要唤起的等待队列
      if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken|mutexStarving) != 0 {
        return
      }
      // 唤起等待队列并数量-1
      new = (old - 1<<mutexWaiterShift) | mutexWoken
      if atomic.CompareAndSwapInt32(&m.state, old, new) {
        runtime_Semrelease(&m.sema, false, 1)
        return
      }
      old = m.state
    }
  } else {
    //饥饿模式,将锁直接给等待队列的队头 goroutine
    runtime_Semrelease(&m.sema, true, 1)
  }
}

感兴趣的朋友可以搜一搜公众号「 阅新技术 」,关注更多的推送文章。

可以的话,就顺便点个赞、留个言、分享下,感谢各位支持!

阅新技术,阅读更多的新知识。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

关注作者,阅读全部精彩内容

我来说两句

0 条评论
登录 后参与评论

相关文章

  • golang 系列:sync.Once 讲解

    之前提到过 Go 的并发辅助对象:WaitGroup。同样的, sync.Once 也是 Go 官方的一并发辅助对象,它能够让函数方法只执行一次,达到类似 in...

    lincoln
  • Golang并发:再也不愁选channel还是选锁

    周末又到了,为大家准备了一份实用干货:如何使用channel和Mutex解决并发问题,利用周末的好时光,配上音乐,思考一下吧?。

    大彬
  • 字节、百度等大厂面经,资深服务端工程师谈跳槽感悟

    今天大鹏请来一位大厂有 4 年工作经验的服务端资深工程师,在2020年多事之秋的节点,跟大家谈一下跳槽感悟,分享一下自己的面试经历

    灵魂画师牧码
  • 锁的使用场景主要涉及到哪些?读写锁为什么会比普通锁快【Golang 入门系列十六】

    前面已经讲过很多Golang系列知识,感兴趣的可以看看以前的文章,https://www.cnblogs.com/zhangweizhong/category/...

    架构师精进
  • C++ RAII实现golang的defer

    在之前一篇文章<<从lock_guard来说一说C++中常用的RAII>> 讲解了RAII, 其实一种常见的资源管理方式,减少了资源泄露的风险。同事和我说是不是...

    河边一枝柳
  • Golang 语言中基础同步原语 Mutex 和 RWMutex 的区别

    Golang 语言天生支持并发,关于并发编程,Golang 语言还有一句口号:“不要通过共享内存进行通信;而是通过通信共享内存”。

    frank.
  • golang之sync.Mutex互斥锁源码分析

    针对Golang 1.9的sync.Mutex进行分析,与Golang 1.10基本一样除了将panic改为了throw之外其他的都一样。

    李海彬
  • Golang并发的次优选择:sync包

    我们都知道Golang并发优选channel,但channel不是万能的,Golang为我们提供了另一种选择:sync。通过这篇文章,你会了解sync包最基础、...

    大彬
  • go sync.Mutex 设计思想与演化过程 --转

    go语言在云计算时代将会如日中天,还抱着.NET不放的人将会被淘汰。学习go语言和.NET完全不一样,它有非常简单的runtime 和 类库。最好的办法就是将整...

    李海彬
  • go sync.Mutex 设计思想与演化过程 (一)

    go语言在云计算时代将会如日中天,还抱着.NET不放的人将会被淘汰。学习go语言和.NET完全不一样,它有非常简单的runtime 和 类库。最好的办法就是将...

    李海彬
  • go sync.Mutex 设计思想与演化过程 (一)

    go语言在云计算时代将会如日中天,还抱着.NET不放的人将会被淘汰。学习go语言和.NET完全不一样,它有非常简单的runtime 和 类库。最好的办法就是将...

    李海彬
  • go sync.Mutex 设计思想与演化过程 --转

    go语言在云计算时代将会如日中天,还抱着.NET不放的人将会被淘汰。学习go语言和.NET完全不一样,它有非常简单的runtime 和 类库。最好的办法就是将整...

    李海彬
  • golang mutex锁的竞争关系浅析

    刚才对golang的锁关系进行 一番思索,想着协程获取golang 对象锁的,是按先按时间先后顺序获取的,其实不然。下面请看代码,顺带写了2种读写锁的应用。

    地球流浪猫
  • Golang并发编程之互斥锁、读写锁详解

    我们对Go语言所提供的与锁有关的API进行说明。这包括了互斥锁和读写锁。我们在第6章描述过互斥锁,但却没有提到过读写锁。这两种锁对于传统的并发程序来说都是非常常...

    会呼吸的Coder
  • GO语言并发编程之互斥锁、读写锁详解

    一、互斥锁 互斥锁是传统的并发程序对共享资源进行访问控制的主要手段。它由标准库代码包sync中的Mutex结构体类型代表。sync.Mutex类型(确切地说,是...

    李海彬
  • Golang 语言中 Channel 的使用方式

    在「Effective Go」并发章节讲到,“不要通过共享内存进行通信;而是通过通信共享内存”。由此表明 Golang 语言官方鼓励用户使用“通过通信共享内存”...

    frank.
  • 透过 rust 探索系统的本原:并发篇

    rust 是一门非常优秀的语言,我虽然没有特别正式介绍过 rust 本身,但其实已经写了好多篇跟 rust 相关的文章:

    tyrchen
  • Golang语言标准库 sync 包的 Once 怎么使用?

    在 Go 语言中,sync 包有一个 Once 类型,官方文档介绍 Once 是一个只执行一次操作的对象。所以,Once 一般用于并发执行,但只需初始化一次的共...

    frank.
  • golang的并发机制

    写出一个高性能的程序,肯定要关注程序的并行特性,那么运行并发,我们关注什么性能指标。比如表象上我们关注 并发的上限,创建并发数据结构的最小开销,切换时间开销。如...

    mariolu

扫码关注云+社区

领取腾讯云代金券