GO的Mutex——庖丁解牛看实现

最新推荐文章于 2024-09-30 21:58:56 发布
最新推荐文章于 2024-09-30 21:58:56 发布
阅读量444 收藏
点赞数 1
分类专栏： go语言 文章标签： go
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zjx130/article/details/109238348
版权

因为有JAVA的基础，学了一些Go语言的基本概念后，打算看看Go的高级特性来换换心情。以下内容摘录整理自《极客时间》晁岳攀（鸟窝）的专栏——《Go 并发编程实战课》
本篇文章通过对Go语言Mutex演进的讲解，让我们对Mutex的理解具有历史的厚度。
Mutex 的架构演进分成了四个阶段，如下图：
在这里插入图片描述
 

初版的互斥锁：

我们先来看怎么实现一个最简单的互斥锁。你可能会想到，可以通过一个 flag 变量，标记当前的锁是否被某个 goroutine 持有。如果这个 flag 的值是 1，就代表锁已经被持有，那么，其它竞争的 goroutine 只能等待；如果这个 flag 的值是 0，就可以通过 CAS（compare-and-swap，或者 compare-and-set）将这个 flag 设置为 1，标识锁被当前的这个 goroutine 持有了。
实际上，Russ Cox 在 2008 年提交的第一版 Mutex 就是这样实现的。


   // CAS操作，当时还没有抽象出atomic包
    func cas(val *int32, old, new int32) bool
    func semacquire(*int32)
    func semrelease(*int32)
    // 互斥锁的结构，包含两个字段
    type Mutex struct {
        key  int32 // 锁是否被持有的标识
        sema int32 // 信号量专用，用以阻塞/唤醒goroutine
    }
    
    // 保证成功在val上增加delta的值
    func xadd(val *int32, delta int32) (new int32) {
        for {
            v := *val
            if cas(val, v, v+delta) {
                return v + delta
            }
        }
        panic("unreached")
    }
    
    // 请求锁
    func (m *Mutex) Lock() {
        if xadd(&m.key, 1) == 1 { //标识加1，如果等于1，成功获取到锁
            return
        }
        semacquire(&m.sema) // 否则阻塞等待
    }
    
    func (m *Mutex) Unlock() {
        if xadd(&m.key, -1) == 0 { // 将标识减去1，如果等于0，则没有其它等待者
            return
        }
        semrelease(&m.sema) // 唤醒其它阻塞的goroutine
    }

Mutex 结构体包含两个字段：

  • 字段 key：是一个 flag，用来标识这个排外锁是否被某个 goroutine 所持有，如果 key 大于等于1，说明这个排外锁已经被持有；
  • 字段 sema：是个信号量变量，用来控制等待 goroutine 的阻塞休眠和唤醒。
    在这里插入图片描述
    初版的 Mutex 利用 CAS 原子操作，对 key 这个标志量进行设置。key 不仅仅标识了锁是否被 goroutine 所持有，还记录了当前持有和等待获取锁的 goroutine 的数量。
    但是，初版的 Mutex 实现有一个问题：请求锁的 goroutine 会排队等待获取互斥锁。虽然这貌似很公平，但是从性能上来看，却不是最优的。因为如果我们能够把锁交给正在占用 CPU 时间片的 goroutine 的话，那就不需要做上下文的切换，在高并发的情况下，可能会有更好的性能。

 

给新人机会：

Go 开发者在 2011 年 6 月 30 日的 commit 中对 Mutex 做了一次大的调整，调整后的 Mutex 实现如下：

   type Mutex struct {
        state int32
        sema  uint32
    }


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

其中，mutexLocked是"给新人机会"的主要实现载体。新人只要发现mutexLocked的状态是未锁，就可以获得锁的执行权。

注：这里的 mutexWoken = 1 << iota
先补充下iota的知识：

1、iota只能在常量的表达式中使用。

>  fmt.Println(iota)   //编译错误： undefined: iota

2、每次const 出现时，都会让 iota 初始化为0。

const a = iota // a=0  
const (   
 b = iota  //b=0   
 c  //c=1   相当于c=iota 
 )

虽然 Mutex 结构体还是包含两个字段，但是第一个字段已经改成了 state，它的含义也不一样了。
state 是一个复合型的字段，一个字段包含多个意义，这样可以通过尽可能少的内存来实现互斥锁。这个字段的第一位（最小的一位）来表示这个锁是否被持有，第二位代表是否有唤醒的 goroutine，剩余的位数代表的是等待此锁的 goroutine 数。
在这里插入图片描述
不过请求锁的方法 Lock 也变得复杂了。


   func (m *Mutex) Lock() {
        // Fast path: 幸运case，能够直接获取到锁
        if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
            return
        }

        awoke := false
        for {
            old := m.state
            new := old | mutexLocked // 新状态加锁
            if old&mutexLocked != 0 {
                new = old + 1<<mutexWaiterShift //等待者数量加一
            }
            if awoke {
                // goroutine是被唤醒的，
                // 新状态清除唤醒标志
                new &^= mutexWoken
            }
            if atomic.CompareAndSwapInt32(&m.state, old, new) {//设置新状态
                if old&mutexLocked == 0 { // 锁原状态未加锁
                    break
                }
                runtime.Semacquire(&m.sema) // 请求信号量
                awoke = true
            }
        }
    }

需要注意的是，Go的运算符优先级和Java不一样。 由上至下代表优先级由高到低：

5 ： * / % << >> & &^
4 ：+ - | ^
3 ：== != < <= > >=
2 ：&&
1 ：||

Lock方法的简单图示：
在这里插入图片描述
再来看看释放锁的 Unlock 方法：


   func (m *Mutex) Unlock() {
        // Fast path: drop lock bit.
        new := atomic.AddInt32(&m.state, -mutexLocked) //去掉锁标志
        if (new+mutexLocked)&mutexLocked == 0 { //本来就没有加锁
            panic("sync: unlock of unlocked mutex")
        }
    
        old := new
        for {
            if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken) != 0 { // 没有等待者，或者有唤醒的waiter，或者锁原来已加锁
                return
            }
            new = (old - 1<<mutexWaiterShift) | mutexWoken // 新状态，准备唤醒goroutine，并设置唤醒标志
            if atomic.CompareAndSwapInt32(&m.state, old, new) {
                runtime.Semrelease(&m.sema)
                return
            }
            old = m.state
        }
    }

解锁首先是将锁的标志位置为0（通过减1的方式），然后再通过复杂的判断，来看看是否要唤醒一个等待的 waiter。若需要唤醒一个waiter，在唤醒之前，需要将 waiter 数量减 1，并且将 mutexWoken 标志设置上，这样，Unlock 就可以返回了。

虽然这一版的 Mutex 已经给新来请求锁的 goroutine 一些机会，让它参与竞争，没有空闲的锁或者竞争失败才加入到等待队列中。但是其实还可以进一步优化。我们接着往下看。

多给些机会：

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


   func (m *Mutex) Lock() {
        // Fast path: 幸运之路，正好获取到锁
        if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
            return
        }

        awoke := false
        iter := 0
        for { // 不管是新来的请求锁的goroutine, 还是被唤醒的goroutine，都不断尝试请求锁
            old := m.state // 先保存当前锁的状态
            new := old | mutexLocked // 新状态设置加锁标志
            if old&mutexLocked != 0 { // 锁还没被释放
                if runtime_canSpin(iter) { // 还可以自旋
                    if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
                        atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
                        // 将锁的唤醒标记置为1，表示已经有醒着的线程正在获取锁，Unlock的时候便无需唤醒新的线程                    
                        awoke = true
                    }
                    runtime_doSpin()
                    iter++
                    continue // 自旋，再次尝试请求锁
                }
                new = old + 1<<mutexWaiterShift
            }
            if awoke { // 唤醒状态
                if new&mutexWoken == 0 {
                    panic("sync: inconsistent mutex state")
                }
                new &^= mutexWoken // 新状态清除唤醒标记
            }
            if atomic.CompareAndSwapInt32(&m.state, old, new) {
                if old&mutexLocked == 0 { // 旧状态锁已释放，新状态成功持有了锁，直接返回
                    break
                }
                runtime_Semacquire(&m.sema) // 阻塞等待
                awoke = true // 被唤醒
                iter = 0
            }
        }
    }

在spin之前， 都会重新检查锁是否释放。对于临界区代码执行非常短的场景来说，这是一个非常好的优化。因为临界区的代码耗时很短，锁很快就能释放，而抢夺锁的 goroutine 不用通过休眠唤醒方式等待调度，直接 spin 几次，可能就获得了锁。
 

解决饥饿：

因为新来的 goroutine 也参与竞争，有可能每次都会被新来的 goroutine 抢到获取锁的机会，在极端情况下，等待中的 goroutine 可能会一直获取不到锁，这就是饥饿问题。
Mutex 不能容忍这种事情发生。所以，2016 年 Go 1.9 中 Mutex 增加了饥饿模式，让锁变得更公平，不公平的等待时间限制在 1 毫秒，并且修复了一个大 Bug：总是把唤醒的 goroutine 放在等待队列的尾部，会导致更加不公平的等待时间。
之后，2018 年，Go 开发者将 fast path 和 slow path 拆成独立的方法，以便内联，提高性能。2019 年也有一个 Mutex 的优化，虽然没有对 Mutex 做修改，但是，对于 Mutex 唤醒后持有锁的那个 waiter，调度器可以有更高的优先级去执行，这已经是很细致的性能优化了。
总的来说，Mutex 绝不容忍一个 goroutine 被落下，永远没有机会获取锁。不抛弃不放弃是它的宗旨，而且它也尽可能地让等待较长的 goroutine 更有机会获取到锁。
在这里插入图片描述


   type Mutex struct {
        state int32
        sema  uint32
    }
    
    const (
        mutexLocked = 1 << iota // mutex is locked
        mutexWoken
        mutexStarving // 从state字段中分出一个饥饿标记
        mutexWaiterShift = iota
    
        starvationThresholdNs = 1e6
    )
    
    func (m *Mutex) Lock() {
        // Fast path: 幸运之路，一下就获取到了锁
        if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
            return
        }
        // Slow path：缓慢之路，尝试自旋竞争或饥饿状态下饥饿goroutine竞争
        m.lockSlow()
    }
    
    func (m *Mutex) lockSlow() {
        var waitStartTime int64
        starving := false // 此goroutine的饥饿标记
        awoke := false // 唤醒标记
        iter := 0 // 自旋次数
        old := m.state // 当前的锁的状态
        for {
            // 锁是非饥饿状态，锁还没被释放，尝试自旋
            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
            if old&mutexStarving == 0 {
                new |= mutexLocked // 非饥饿状态，加锁
            }
            if old&(mutexLocked|mutexStarving) != 0 {
                new += 1 << mutexWaiterShift // waiter数量加1
            }
            if starving && old&mutexLocked != 0 {
                new |= mutexStarving // 设置饥饿状态
            }
            // 不管是获得了锁还是进入休眠，我们都需要清除 mutexWoken 标记
            if awoke {
                if new&mutexWoken == 0 {
                    throw("sync: inconsistent mutex state")
                }
                new &^= mutexWoken // 新状态清除唤醒标记
            }
            // 成功设置新状态
            if atomic.CompareAndSwapInt32(&m.state, old, new) {
                // 原来锁的状态已释放，并且不是饥饿状态，正常请求到了锁，返回
                if old&(mutexLocked|mutexStarving) == 0 {
                    break // locked the mutex with CAS
                }
                // 处理饥饿状态

                // 如果以前就在队列里面，加入到队列头
                queueLifo := waitStartTime != 0
                if waitStartTime == 0 {
                    waitStartTime = runtime_nanotime()
                }
                // 阻塞等待
                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")
                    }
                    // 加锁并且将waiter数减1（加mutexLocked是加锁，减1<<mutexWaiterShift是减少waiter）
                    delta := int32(mutexLocked - 1<<mutexWaiterShift)
                    if !starving || old>>mutexWaiterShift == 1 {
                        delta -= mutexStarving // 最后一个waiter或者已经不饥饿了，清除饥饿标记
                        // （同理，减mutexStarving是清楚饥饿标记）
                    }
                    atomic.AddInt32(&m.state, delta)
                    break
                }
                awoke = true
                iter = 0
            } else {
                old = m.state
            }
        }
    }
    
    func (m *Mutex) Unlock() {
        // Fast path: drop lock bit.
        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
                }
                new = (old - 1<<mutexWaiterShift) | mutexWoken
                if atomic.CompareAndSwapInt32(&m.state, old, new) {
                    runtime_Semrelease(&m.sema, false, 1)
                    return
                }
                old = m.state
            }
        } else {
            runtime_Semrelease(&m.sema, true, 1)
        }
    }

通过Mutex的演进，我们可以看到，程序 80% 的主要特性，只需20%的代码。但程序 20% 的优化特性，可能需要额外的80% 的代码。这也是程序越来越复杂的原因

全麦小面包
关注
专栏目录
Go语言Mutex的优化与TryLock机制解析
一个被知识诅咒的人
09-24 502
本文详细介绍了Go语言中Mutex锁的实现、优化过程及TryLock机制的应用。通过对Mutex结构、锁的获取与释放、自旋与饥饿问题的解决方案等方面的深入分析，展示了Go语言在高并发环境下的锁管理机制。此外，本文还重点讨论了TryLock方法的实现与使用场景，分析了其局限性和使用中的注意事项，为开发者提供了有效的并发锁优化参考。
Go死锁——当Channel遇上Mutex时
pythonxxoo的博客
07-13 536
最近，我在测试ws长链接网关，平均一个星期会遇到一次服务假死问题，因为并不是所有routine被阻塞，故runtime的检查无法触发，http health check又是另开的一个端口，k8s检查不到异常，无法重启服务。 经过一番排查论证之后，确定了是 **混用带缓冲的Channel和Metux造成的死锁 （具体在文末总结）**问题，请看下面详细介绍。我们使用了gin框架，预先接入了pprof封装组件，这样通过http（非生产）就能很方便的查看go runtime的一些信息。 果不其然，我们打
Go-知识并发控制mutex
a18792721831的博客
06-15 1122
互斥锁是并发程序中对共享资源进行访问控制的主要手段，Go 语言提供了非常简单易用的 Mutex。Mutex 是结构体类型，对外暴露了 Lock 和 Unlock 两个方法，用于加锁和解锁。自旋对应于CPU的PAUSE指令，CPU对该指令什么都不做，相当于CPU空转，对程序而言相当于sleep了一小段时间，时间非常短，当前实现是 30个时钟周期。自旋过程中会持续探测 Locked 是否变为0 ，连续两次探测奸恶就是在执行这些 PAUSE 指令，不同于sleep，不需要将协程转为睡眠状态。
go中的Mutex
白小白的小白的博客
09-01 1963
go mutex
互斥量mutex、锁、条件变量和信号量相关原语（函数）----很全
最新发布
caiji0169的博客
09-30 994
Linux下c/c++编程，互斥量mutex函数（pthread_mutex_init、pthread_mutex_lock....），读写锁（pthread_mutex_trylock、pthread_rwlock_rdlock.....）、条件变量函数（pthread_cond_init.....）、信号量函数（sem_init....）介绍和使用
Go并发编程（1）-Mutex源码实现
Zerore的博客
09-08 230
Mutex：如何解决资源并发访问问题 多线程访问共享资源，通过互斥锁来实现，其根本是对共享内存的锁定？（如果是多进程，还能简单使用互斥锁吗，是否需要分布式锁？） 同步原语的使用场景： 共享资源。并发地读写共享资源，会出现数据竞争（data race）的问题，所以需要 Mutex、RWMutex 这样的并发原语来保护。 任务编排。需要 goroutine 按照一定的规律执行，而 goroutine 之间有相互等待或者依赖的顺序关系，我们常常使用 WaitGroup 或者 Channel 来实现。 消息传递。
go通过Mutex实现互斥锁(Mutex原理)
k393393的博客
01-17 529
在 Go 语言里通过 Mutex实现互斥锁 Mutex接口定义 type Locker interface { Lock() //加锁 Unlock() //释放锁 } Mutex原理 1、原理图说明 2、只有一个协程在抢锁 3、协程解锁 4、协程1加锁后释放，协程2抢锁成功 以下是通过Mutex实现的加锁 package main import ( "fmt" "sync" "time" ) var wg sync.WaitGroup var lock sync.Mu
Golang中Mutex的实现
samson
11-13 2351
一.Golang中的锁 Golang的提供的同步机制有sync模块下的Mutex、WaitGroup以及语言自身提供的chan等。 这些同步的方法都是以runtime中实现的底层同步机制（cas、atomic、spinlock、sem）为基础的。 1 cas(Compare And Swap)和原子运算是其他同步机制的基础 原子操作：指那些不能够被打断的操作被称为原子操作，当有...
图解：Go Mutex
Voryla的博客
12-06 493
Mutex 可能处于两种不同的模式：正常模式和饥饿模式。在正常模式下，新来的G会尝试自旋获取锁，如果自旋获取失败，则会按照FIFO的顺序排队获取锁。当Mutex被释放，会唤醒等待队列中第一个等待者G，它需要和新来的 G们竞争Mutex的使用权。而新来的G会更有优势，它们已经在CPU上运行且它们的数量更多。因此一个刚被唤醒的等待者很大概率获取不到锁，在这种情况下，它会被放置到等待队列的队首。[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xht5oJlA-167029119359
Linux驱动开发庖丁解牛
03-25
通过"Linux驱动开发庖丁解牛"的学习，开发者可以逐步掌握从驱动开发环境的搭建到实际驱动程序编写的所有步骤，理解Linux内核与硬件设备间的交互机制，为实现高效、稳定的硬件支持奠定坚实基础。所提供的两份PDF文档...
go mutex详解
qq_44800780的博客
02-24 2813
数据结构 type Mutex struct { state int32 sema uint32 } state表示mutex的状态，是32位的整型变量，内部实现时把该变量分成四份，用于记录Mutex的四种状态 Locked: 表示该Mutex是否已被锁定，0：没有锁定 1：已被锁定。 Woken: 表示是否有协程已被唤醒，0：没有协程唤醒 1：已有协程唤醒，正在加锁过程中。 Starving：表示该Mutex是否处于饥饿状态，0：没有饥饿 1：饥饿状态，说明有协程阻塞了超过1ms。 Waiter
go语言五——http模块实现个状态计数器
08-03
在Go语言中，HTTP模块是构建网络服务的核心部分，它提供了强大的功能，使得开发者能够轻松地创建Web服务器和客户端。本篇文章将深入探讨如何利用Go的http模块来实现一个状态计数器。状态计数器通常用于记录HTTP请求...
Go 中的锁源码实现：Mutex
wanwan880818的博客
06-06 607
上一篇文章《当我们谈论锁，我们谈什么》 中我提到了锁，准确地说是信号量（semaphore, mutext是semaphore的一种）的实现方式有两种：wait的时候忙等待或者阻塞自己。1234567891011121314//忙等待wait(S) {    while(S&lt;=0)        ;   //no-op    S--}//阻塞wait(semaphore *S) {    S...
golang中锁mutex的实现
baiyan1009的博客
12-04 277
golang中的锁是通过CAS原子操作实现的，Mutex结构如下： type Mutex struct { state int32 semauint32 } //state表示锁当前状态，每个位都有意义，零值表示未上锁 //sema用做信号量，通过PV操作从等待队列中阻塞/唤醒goroutine，等待锁的gor...
go的Mutex实现原理及演进
z3551906947的博客
07-19 1288
深入理解Mutex：通过学习 Mutex 的实现，我更深入地理解了并发编程中的同步机制和挑战。性能与公平性的权衡：理解了在设计并发系统时，性能和公平性之间的权衡是不可避免的。代码实践的重要性：理论知识需要通过实践来巩固，实际编写和测试并发代码是提高理解的关键。通过这些笔记，我希望能够更好地理解和应用 Go 语言中的并发原语，编写出更高效、更可靠的并发程序。同时，这些知识也为我提供了一个思考并发编程问题的框架，帮助我在面对并发挑战时做出更明智的设计决策。
go mutex实现分析
baidu_20390857的博客
02-20 917
mutex有两个成员，state和sema。其中state表示当前互斥锁的状态，而sema是用于控制锁状态的信号量。有两个要实现的接口，加锁和解锁。state是一个32位的值，第一位是加锁标记，第二位是唤醒标记，第三位是饥饿标记，之后的位数用来记录等待队列的数量。mutexWoken互斥锁有两种操作模式：普通模式和饥饿模式。在普通模式下，等待者按照先进先出（FIFO）的顺序排队，但是被唤醒的等待者不拥有互斥锁，而是与新到达的 goroutine 竞争互斥锁的所有权。
go的mutex如何实现？
weixin_34232363的博客
03-18 298
为什么80%的码农都做不了架构师？>>> ...
初见 Go Mutex
u012948302的专栏
04-28 247
本篇文章我们介绍了Go语言中的互斥锁 sync.Mutex，包括为什么要使用、如何使用以及可能会踩坑的问题，尝试用起来吧！
Go语言的Mutex
qq497811258的博客
10-26 345
在本教程中，我们将了解互斥体。我们还将学习如何使用解决竞争条件。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值