深入理解Go语言中的sync.Cond
创始人
2025-05-31 09:44:13
0

1. 简介

本文将介绍 Go 语言中的 sync.Cond并发原语,包括 sync.Cond的基本使用方法、实现原理、使用注意事项以及常见的使用使用场景。能够更好地理解和应用 Cond 来实现 goroutine 之间的同步。

2. 基本使用

2.1 定义

sync.Cond是Go语言标准库中的一个类型,代表条件变量。条件变量是用于多个goroutine之间进行同步和互斥的一种机制。sync.Cond可以用于等待和通知goroutine,以便它们可以在特定条件下等待或继续执行。

2.2 方法说明

sync.Cond的定义如下,提供了Wait ,Singal,Broadcast以及NewCond方法

type Cond struct {noCopy noCopy// L is held while observing or changing the conditionL Lockernotify  notifyListchecker copyChecker
}func NewCond(l Locker) *Cond {}
func (c *Cond) Wait() {}
func (c *Cond) Signal() {}
func (c *Cond) Broadcast() {}
  • NewCond方法: 提供创建Cond实例的方法
  • Wait方法: 使当前线程进入阻塞状态,等待其他协程唤醒
  • Singal方法: 唤醒一个等待该条件变量的线程,如果没有线程在等待,则该方法会立即返回。
  • Broadcast方法: 唤醒所有等待该条件变量的线程,如果没有线程在等待,则该方法会立即返回。

2.3 使用方式

当使用sync.Cond时,通常需要以下几个步骤:

  • 定义一个互斥锁,用于保护共享数据;
  • 创建一个sync.Cond对象,关联这个互斥锁;
  • 在需要等待条件变量的地方,获取这个互斥锁,并使用Wait方法等待条件变量被通知;
  • 在需要通知等待的协程时,使用SignalBroadcast方法通知等待的协程。
  • 最后,释放这个互斥锁。

下面是一个简单的代码的示例,展示了大概的代码结构:

var (// 1. 定义一个互斥锁mu    sync.Mutexcond  *sync.Condcount int
)
func init() {// 2.将互斥锁和sync.Cond进行关联cond = sync.NewCond(&mu)
}
go func(){// 3. 在需要等待的地方,获取互斥锁,调用Wait方法等待被通知mu.Lock()// 这里会不断循环判断 是否满足条件for !condition() {cond.Wait() // 等待任务}mu.Unlock()
}go func(){// 执行业务逻辑// 4. 满足条件,此时调用Broadcast唤醒处于等待状态的协程cond.Broadcast() 
}

2.4 使用例子    

下面通过描述net/http中的 connReader,来展示使用sync.Cond实现阻塞等待通知的机制。这里我们不需要理解太多,只需要知道connReader下面两个方法:

func (cr *connReader) Read(p []byte) (n int, err error) {}
func (cr *connReader) abortPendingRead() {}

Read方法则是用于从HTTP连接中读取数据,不允许并发访问的。而abortPendingRead则是用于终止正在读取的连接。

abortPendingRead方法的语意来看,是需要成功终止其他协程进行数据的读取之后,才能正常返回,也就是此时没有协程再继续读取数据了,才可以返回。

那abortPendingRead如何得知是否还有协程在读取数据呢,其实是可以通过定时轮训connReader的状态,从而判断当前Read方法是否仍在读取数据。但是定时轮训效率太低,可能会造成cpu的大量空转。更好的方式,应该是让协程进入阻塞状态,然后等条件满足了,其他协程再来唤醒当前协程,然后再继续运行下去。

这个其实就是sync.Cond设计的用途,当不满足运行条件时,先进入阻塞状态,等待条件满足时,再由其他协程来唤醒,然后再继续运行下去,能够提高程序的执行效率。其中Wait方法便是让协程进入阻塞状态,而SingalBoardcast便是唤醒处于阻塞状态的协程,告知其条件满足了,可以继续向下执行了。

回到我们connReader的例子,我们使用sync.Cond实现阻塞等待通知的效果。

type connReader struct {// 是否正在读取数据inRead boolmu      sync.Mutex // guards followingcond    *sync.Cond
}func (cr *connReader) abortPendingRead() {if !cr.inRead{return}//1. 通过一定手段,让Read方法中断cr.mu.Lock()// 判断Read方法是否仍然在读取数据for cr.inRead {//2. 此时Read方法仍然在读取数据, 不满足条件,等待通知cr.cond.Wait()}cr.mu.Unlock()
}func (cr *connReader) Read(p []byte) (n int, err error) {cr.mu.Lock()cr.inRead = true// 1. 读取数据// 2. abortPendingRead通过某种手段,让Read方法中断cr.inRead = falsecr.mu.Unlock()// 3. 现在已经满足abortPendingRead继续执行下去的条件了,可以唤醒abortPendingRead协程了cond.Boardcast()
}

这里abortPendingRead方法首先判断是否还在读取数据,是的话,调用Wait方法进入阻塞状态,等待条件满足后继续执行。

对于Read方法,因为其不运行并发访问,当其将退出时,说明此时已经没有协程在读取数据了,满足abortPendingRead继续执行下去的条件了,此时可以调用Boardcast来唤醒等待条件满足的协程。之后调用abortPendingRead方法的协程此时能够接收到通知,便能够顺利被唤醒,从而正确返回。

这里便展示了一个简单的,使用sync.Cond实现阻塞等待通知的例子。

3. 原理

3.1 基本原理

Sync.Cond存在一个通知队列,保存了所有处于等待状态的协程。通知队列定义如下:

type notifyList struct {wait   uint32notify uint32lock   uintptr // key field of the mutexhead   unsafe.Pointertail   unsafe.Pointer
}

当调用Wait方法时,此时Wait方法会释放所持有的锁,然后将自己放到notifyList等待队列中等待。此时会将当前协程加入到等待队列的尾部,然后进入阻塞状态。

当调用Signal 时,此时会唤醒等待队列中的第一个协程,其他继续等待。如果此时没有处于等待状态的协程,调用Signal不会有其他作用,直接返回。当调用BoradCast方法时,则会唤醒notfiyList中所有处于等待状态的协程。

sync.Cond的代码实现比较简单,协程的唤醒和阻塞已经由运行时包实现了,sync.Cond的实现直接调用了运行时包提供的API。

3.2 实现

 3.2.1 Wait方法实现

Wait方法首先调用runtime_notifyListAd方法,将自己加入到等待队列中,然后释放锁,等待其他协程的唤醒。

func (c *Cond) Wait() {// 将自己放到等待队列中t := runtime_notifyListAdd(&c.notify)// 释放锁c.L.Unlock()// 等待唤醒runtime_notifyListWait(&c.notify, t)// 重新获取锁c.L.Lock()
}

3.2.2 Singal方法实现

Singal方法调用runtime_notifyListNotifyOne唤醒等待队列中的一个协程。

func (c *Cond) Signal() {// 唤醒等待队列中的一个协程runtime_notifyListNotifyOne(&c.notify)
}

3.2.3 Broadcast方法实现

Broadcast方法调用runtime_notifyListNotifyAll唤醒所有处于等待状态的协程。

func (c *Cond) Broadcast() {// 唤醒等待队列中所有的协程runtime_notifyListNotifyAll(&c.notify)
}

4.使用注意事项

4.1 调用Wait方法前未加锁

4.1.1 问题

如果在调用Wait方法前未加锁,此时会直接panic,下面是一个简单例子的说明:

package mainimport ("fmt""sync""time"
)var (count intcond  *sync.Condlk    sync.Mutex
)func main() {cond = sync.NewCond(&lk)wg := sync.WaitGroup{}wg.Add(2)go func() {defer wg.Done()for {time.Sleep(time.Second)count++cond.Broadcast()}}()go func() {defer wg.Done()for {time.Sleep(time.Millisecond * 500)          //cond.L.Lock() for count%10 != 0 {cond.Wait()}t.Logf("count = %d", count)//cond.L.Unlock()  }}()wg.Wait()
}

上面代码中,协程一每隔1s,将count字段的值自增1,然后唤醒所有处于等待状态的协程。协程二执行的条件为count的值为10的倍数,此时满足执行条件,唤醒后将会继续往下执行。

但是这里在调用sync.Wait方法前,没有先获取锁,下面是其执行结果,会抛出 fatal error: sync: unlock of unlocked mutex 错误,结果如下:

count = 0
fatal error: sync: unlock of unlocked mutex

因此,在调用Wait方法前,需要先获取到与sync.Cond关联的锁,否则会直接抛出异常。

4.1.2 为什么调用Wait方法前需要先获取该锁

强制调用Wait方法前需要先获取该锁。这里的原因在于调用Wait方法如果不加锁,有可能会出现竞态条件。

这里假设多个协程都处于等待状态,然后一个协程调用了Broadcast唤醒了其中一个或多个协程,此时这些协程都会被唤醒。

如下,假设调用Wait方法前没有加锁的话,那么所有协程都会去调用condition方法去判断是否满足条件,然后都通过验证,执行后续操作。

for !condition() {c.Wait()
}
c.L.Lock()
// 满足条件情况下,执行的逻辑
c.L.Unlock()

此时会出现的情况为,本来是需要在满足condition方法的前提下,才能执行的操作。现在有可能的效果,为前面一部分协程执行时,还是满足condition条件的;但是后面的协程,尽管不满足condition条件,还是执行了后续操作,可能导致程序出错。

正常的用法应该是,在调用Wait方法前便加锁,只会有一个协程判断是否满足condition条件,然后执行后续操作。这样子就不会出现即使不满足条件,也会执行后续操作的情况出现。

c.L.Lock()
for !condition() {c.Wait()
}
// 满足条件情况下,执行的逻辑
c.L.Unlock()

4.2 Wait方法接收到通知后,未重新检查条件变量

调用sync.Wait方法,协程进入阻塞状态后被唤醒,没有重新检查条件变量,此时有可能仍然处于不满足条件变量的场景下。然后直接执行后续操作,有可能会导致程序出错。下面举一个简单的例子:

package mainimport ("fmt""sync""time"
)var (count intcond  *sync.Condlk    sync.Mutex
)func main() {cond = sync.NewCond(&lk)wg := sync.WaitGroup{}wg.Add(3)go func() {defer wg.Done()for {time.Sleep(time.Second)cond.L.Lock()// 将flag 设置为trueflag = true// 唤醒所有处于等待状态的协程cond.Broadcast()cond.L.Unlock()}}()for i := 0; i < 2; i++ {go func(i int) {defer wg.Done()for {time.Sleep(time.Millisecond * 500)cond.L.Lock()// 不满足条件,此时进入等待状态if !flag {cond.Wait()}// 被唤醒后,此时可能仍然不满足条件fmt.Printf("协程 %d flag = %t", i, flag)flag = falsecond.L.Unlock()}}(i)}wg.Wait()
}

在这个例子,我们启动了一个协程,定时将flag设置为true,相当于每隔一段时间,便满足执行条件,然后唤醒所有处于等待状态的协程。

然后又启动了两个协程,在满足条件的前提下,开始执行后续操作,但是这里协程被唤醒后,没有重新检查条件变量,具体看第39行。这里会出现的场景是,第一个协程被唤醒后,此时执行后续操作,然后将flag重新设置为false,此时已经不满足条件了。之后第二个协程唤醒后,获取到锁,没有重新检查此时是否满足执行条件,直接向下执行,这个就和我们预期不符,可能会导致程序出错,代码执行效果如下:

协程 1 flag = true
协程 0 flag = false
协程 1 flag = true
协程 0 flag = false

可以看到,此时协程0执行时,flag的值均为false,说明此时其实并不符合执行条件,可能会导致程序出错。因此正确用法应该像下面这样子,被唤醒后,需要重新检查条件变量,满足条件之后才能继续向下执行。

c.L.Lock()
// 唤醒后,重新检查条件变量是否满足条件
for !condition() {c.Wait()
}
// 满足条件情况下,执行的逻辑
c.L.Unlock()

5.总结

本文介绍了 Go 语言中的 sync.Cond 并发原语,它是用于实现 goroutine 之间的同步的重要工具。我们首先学习了 sync.Cond 的基本使用方法,包括创建和使用条件变量、使用WaitSignal/Broadcast方法等。

在接下来的部分中,我们介绍了 sync.Cond 的实现原理,主要是对等待队列的使用,从而sync.Cond有更好的理解,能够更好得使用它。同时,我们也讲述了使用sync.Cond的注意事项,如调用Wait方法前需要加锁等。

基于以上内容,本文完成了对 sync.Cond 的介绍,希望能够帮助大家更好地理解和使用Go语言中的并发原语。

相关内容

热门资讯

安卓系统和oppo系统哪个流畅... 你有没有想过,手机系统哪个更流畅呢?安卓系统和OPPO系统,这两个名字听起来就让人心动。今天,咱们就...
安卓怎么用微软系统,利用微软系... 你是不是也和我一样,对安卓手机上的微软系统充满了好奇?想象那熟悉的Windows界面在你的安卓手机上...
安卓系统如何安装nfc,安卓系... 你有没有想过,用手机刷公交卡、支付账单,是不是比掏出钱包来得酷炫多了?这就得归功于NFC技术啦!今天...
ios系统可以转安卓,跨平台应... 你有没有想过,你的iPhone手机里的那些宝贝应用,能不能搬到安卓手机上继续使用呢?没错,今天就要来...
iOSapp移植到安卓系统,i... 你有没有想过,那些在iOS上让你爱不释手的app,是不是也能在安卓系统上大放异彩呢?今天,就让我带你...
现在安卓随便换系统,探索个性化... 你知道吗?现在安卓手机换系统简直就像换衣服一样简单!没错,就是那种随时随地、随心所欲的感觉。今天,就...
安卓系统安装按钮灰色,探究原因... 最近发现了一个让人头疼的小问题,那就是安卓手机的安装按钮突然变成了灰色,这可真是让人摸不着头脑。你知...
安卓7.1.1操作系统,系统特... 你知道吗?最近我在手机上发现了一个超级酷的新玩意儿——安卓7.1.1操作系统!这可不是什么小打小闹的...
安卓os系统怎么设置,并使用`... 你有没有发现,你的安卓手机有时候就像一个不听话的小孩子,有时候设置起来真是让人头疼呢?别急,今天就来...
安卓降低系统版本5.1,探索安... 你知道吗?最近安卓系统又来了一次大动作,竟然把系统版本给降到了5.1!这可真是让人有点摸不着头脑,不...
解放安卓系统被保护,解放安卓系... 你有没有想过,你的安卓手机其实可以更加自由地呼吸呢?是的,你没听错,我说的就是解放安卓系统被保护的束...
校务帮安卓系统下载,便捷校园生... 你有没有想过,你的手机里装了一个神奇的助手——校务帮安卓系统下载?没错,就是那个能让你轻松管理学校事...
安卓系统没有拼多多,拼多多崛起... 你知道吗?最近我在手机上发现了一个小小的秘密,那就是安卓系统里竟然没有拼多多这个应用!这可真是让我大...
甜城麻将安卓系统,解锁全新麻将... 你有没有听说过那个超级火的甜城麻将安卓系统?没错,就是那个让无数麻将爱好者为之疯狂的软件!今天,就让...
安卓系统卸载的软件,深度揭秘卸... 手机里的软件越来越多,是不是感觉内存不够用了?别急,今天就来教你怎么在安卓系统里卸载那些不再需要的软...
安卓系统推荐好游戏,畅享指尖乐... 手机里的游戏可是咱们休闲娱乐的好伙伴,尤其是安卓系统的用户,选择面那可是相当广呢!今天,就让我来给你...
王者安卓系统怎么卖,揭秘如何轻... 你有没有听说最近王者安卓系统的火爆程度?没错,就是那个让无数玩家沉迷其中的王者荣耀!今天,我就来给你...
安卓开发系统内置证书,基于安卓... 你有没有想过,你的安卓手机里那些神秘的内置证书,它们到底是个啥玩意儿?别急,今天就来给你揭秘这些隐藏...
荣耀安装安卓原生系统,深度体验... 你知道吗?最近荣耀手机界可是掀起了一股热潮,那就是——荣耀安装安卓原生系统!这可不是什么小打小闹,而...
安卓13小米系统,创新功能与流... 你知道吗?最近安卓13系统可谓是风头无两,各大手机厂商纷纷推出自家的新版系统,其中小米的安卓13系统...