这一次,彻底搞懂 Go Cond
hi,大家好,我是 haohongfan。
本篇文章会从源码角度去深入剖析下 sync.Cond。Go 日常开发中 sync.Cond 可能是我们用的较少的控制并发的手段,因为大部分场景下都被 Channel 代替了。还有就是 sync.Cond 使用确实也蛮复杂的。
比如下面这段代码:
package main
import (
"fmt"
"time"
)
func main() {
done := make(chan int, 1)
go func() {
time.Sleep(5 * time.Second)
done <- 1
}()
fmt.Println("waiting")
<-done
fmt.Println("done")
}
同样可以使用 sync.Cond 来实现
package main
import (
"fmt"
"sync"
"time"
)
func main() {
cond := sync.NewCond(&sync.Mutex{})
var flag bool
go func() {
time.Sleep(time.Second * 5)
cond.L.Lock()
flag = true
cond.Signal()
cond.L.Unlock()
}()
fmt.Println("waiting")
cond.L.Lock()
for !flag {
cond.Wait()
}
cond.L.Unlock()
fmt.Println("done")
}
大部分场景下使用 channel 是比 sync.Cond方便的。不过我们要注意到,sync.Cond 提供了 Broadcast 方法,可以通知所有的等待者。想利用 channel 实现这个方法还是不容易的。我想这应该是 sync.Cond 唯一有用武之地的地方。
先列出来一些问题吧,可以带着这些问题来阅读本文:
-
cond.Wait本身就是阻塞状态,为什么 cond.Wait 需要在循环内 ? -
sync.Cond 如何触发不能复制的 panic ? -
为什么 sync.Cond 不能被复制 ? -
cond.Signal 是如何通知一个等待的 goroutine ? -
cond.Broadcast 是如何通知等待的 goroutine 的?
源码剖析
sync.Cond 排队动图
cond.Wait 是阻塞的吗?是如何阻塞的?
是阻塞的。不过不是 sleep 这样阻塞的。
调用 goparkunlock
解除当前 goroutine 的 m 的绑定关系,将当前 goroutine 状态机切换为等待状态。等待后续 goready 函数时候能够恢复现场。
cond.Signal 是如何通知一个等待的 goroutine ?
-
判断是否有没有被唤醒的 goroutine,如果都已经唤醒了,直接就返回了 -
将已通知 goroutine 的数量加1 -
从等待唤醒的 goroutine 队列中,获取 head 指针指向的 goroutine,将其重新加入调度 -
被阻塞的 goroutine 可以继续执行
cond.Broadcast 是如何通知等待的 goroutine 的?
-
判断是否有没有被唤醒的 goroutine,如果都已经唤醒了,直接就返回了 -
将等待通知的 goroutine 数量和已经通知过的 goroutine 数量设置成相等 -
遍历等待唤醒的 goroutine 队列,将所有的等待的 goroutine 都重新加入调度 -
所有被阻塞的 goroutine 可以继续执行
cond.Wait本身就是阻塞状态,为什么 cond.Wait 需要在循环内 ?
我们能注意到,调用 cond.Wait 的位置,使用的是 for 的方式来调用 wait 函数,而不是使用 if 语句。
这是由于 wait 函数被唤醒时,存在虚假唤醒等情况,导致唤醒后发现,条件依旧不成立。因此需要使用 for 语句来循环地进行等待,直到条件成立为止。
使用中注意点
1. 不能不加锁直接调用 cond.Wait
func (c *Cond) Wait() {
c.checker.check()
t := runtime_notifyListAdd(&c.notify)
c.L.Unlock()
runtime_notifyListWait(&c.notify, t)
c.L.Lock()
}
我们看到 Wait 内部会先调用 c.L.Unlock(),来先释放锁。如果调用方不先加锁的话,会触发“fatal error: sync: unlock of unlocked mutex”。关于 mutex 的使用方法,推荐阅读下《这可能是最容易理解的 Go Mutex 源码剖析》
2. 为什么不能 sync.Cond 不能复制 ?
sync.Cond 不能被复制的原因,并不是因为 sync.Cond 内部嵌套了 Locker。因为 NewCond 时传入的 Mutex/RWMutex 指针,对于 Mutex 指针复制是没有问题的。
主要原因是 sync.Cond 内部是维护着一个 notifyList。如果这个队列被复制的话,那么就在并发场景下导致不同 goroutine 之间操作的 notifyList.wait、notifyList.notify 并不是同一个,这会导致出现有些 goroutine 会一直堵塞。
这里留下一个问题,sync.Cond 内部是有一段代码 check sync.Cond 是不能被复制的,下面这段代码能触发这个 panic 吗?
package main
import (
"fmt"
"sync"
)
func main() {
cond1 := sync.NewCond(new(sync.Mutex))
cond := *cond1
fmt.Println(cond)
}
有兴趣的可以动手尝试下,以及尝试下如何才能触发这个panic "sync.Cond is copied” 。
sync.Cond 的剖析到这里基本就结束了。有什么想跟我交流的,欢迎评论区留言。
欢迎关注我的公众号,随时关注我的动态
sync.Cond 完整流程图获取链接:链接:https://pan.baidu.com/s/1DjtfCyCua0nGYB6TOSsYWA 密码: wn02。其他模块流程图,请关注公众号回复1获取。
学习资料分享,关注公众号回复指令:
-
回复 0,获取 《Go 面经》 -
回复 1,获取 《Go 源码流程图》
本文分享自微信公众号 - HHFCodeRv(hhfcodearts)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
回溯问题中组合、子集和排列问题的去重
回溯法,⼀般可以解决如下⼏种问题: 组合问题:N个数⾥⾯按⼀定规则找出k个数的集合 切割问题:⼀个字符串按⼀定规则有⼏种切割⽅式 ⼦集问题:⼀个N个数的集合⾥有多少符合条件的⼦集 排列问题:N个数按⼀定规则全排列,有⼏种排列⽅式 棋盘问题:N皇后,解数独等等 本文主要讲解这几种问题在去重问题上的不同做法,其实就一个核心点,<font color=red>对有序数组进行去重,去重方式包括传递used引用去重和每层定义set去重</font>。 需知:组合问题、切割问题和子集问题无序,排列问题有序 对于组合问题,因为组合无序,所以需要排序+used/set去重,组合问题其实是子集问题的一种; 对于切割问题,本质就是组合问题,使用startIdx当作切割下标即可; 对于子集问题,包括两种题型: 子集II:和组合问题去重一样,排序+used/set去重 递增子序列:等价于从有序数组中选取所有子集,相当于有序数组的前提已经实现,所以需要使用set进行去重,不能使用used是因为不能进行candidates[i] == candidates[i-1] && ...
- 下一篇
线上消息堆积与感想
【环境介绍】 1.应用服务器部署在阿里云 2.消息中间件使用阿里云RocketMQ 前两天线上发生了MQ消息堆积的情况,在我的知识认知里,消息堆积的原因是消费者消费能力差,无法及时消费消息,才会导致消息堆积. 那么有哪些因素会导致消费者消费能力差呢? 我目前的理解有三种情况 1.Dubbo的RPC调用时间太久 2.查询数据库或者插入数据太久 3.业务中还有其他耗时操作,比如发送邮件 记得以前看博客的时候,似乎看到过说发送邮件耗时久导致消息堆积的情况, 而现在就发生在自己身上,真是冥冥之中自有安排. 发生消息堆积,查看阿里云上的线程堆栈信息 从线程堆栈上来看,线程在发送邮件,准确说在连接. 根据代码分析以及一段时间的观察线程,断定就是发送邮件的逻辑导致的.临时注释掉这段代码,重新发布,问题解决. 其实发送邮件并不会耗时太久, 而根据阿里云ARMS上的错误显示,消息消费失败总耗时2min. 为什么发送邮件(准确说是连接)会这么久. 因为那段发送邮件的代码在本地测试,只耗时1s左右. <dependency> <groupId>javax.mail</grou...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS关闭SELinux安全模块
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS6,CentOS7官方镜像安装Oracle11G
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Red5直播服务器,属于Java语言的直播服务器
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS8安装Docker,最新的服务器搭配容器使用