专栏首页roseduan写字的地方面试高频:Go语言死锁与goroutine泄露问题谈论

面试高频:Go语言死锁与goroutine泄露问题谈论

★本节源码位置 https://github.com/golang-minibear2333/golang/blob/master/4.concurrent/4.4-deadlock/ ”

什么时候会导致死锁

在计算机组成原理里说过 死锁有三个必要条件他们分别是 循环等待、资源共享、非抢占式,在并发中出现通道死锁只有两种情况:

  • 数据要发送,但是没有人接收
  • 数据要接收,但是没有人发送

发送单个值时的死锁

牢记这两点问题就很清晰了,复习下之前的例子,会死锁

a := make(chan int)
a <- 1   //将数据写入channel
z := <-a //从channel中读取数据
  • 有且只有一个协程时,无缓冲的通道
  • 先发送会阻塞在发送,先接收会阻塞在接收处。
  • 发送操作在接收者准备好之前是阻塞的,接收操作在发送之前是阻塞的,
  • 解决办法就是改为缓冲通道,或者使用协程配对

解决方法一,协程配对,先发送还是先接收无所谓只要配对就好

chanInt := make(chan int)
go func() {
    chanInt <- 1
}()

res := <-chanInt

解决方法二,缓冲通道

chanInt := make(chan int,1)
chanInt <- 2
res := <-chanInt
  • 缓冲通道内部的消息数量用len()函数可以测试出来
  • 缓冲通道的容量可以用cap()测试出来
  • 在满足cap>len时候,因为没有满,发送不会阻塞
  • len>0时,因为不为空,所以接收不会阻塞

使用缓冲通道可以让生产者和消费者减少阻塞的可能性,对异步操作更友好,不用等待对方准备,但是容量不应设置过大,不然会占用较多内存。

多个值发送的死锁

配对可以让死锁消失,但发送多个值的时候又无法配对了,又会死锁

func multipleDeathLock() {
 chanInt := make(chan int)
 defer close(chanInt)
    go func() {
  res := <-chanInt
  fmt.Println(res)
 }()
 chanInt <- 1
 chanInt <- 1
}

不出所料死锁了

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan send]:
main.multipleDeathLock()

只有在工作中通知信号是一对一的情况,通知一次以后就不再使用了,其他这种要求多次读写配对的情况根本不会存在。

解决多值发送死锁

更常见的是用循环来不断接收值,接受一个处理一个,如下:

func multipleLoop() {
 chanInt := make(chan int)
 defer close(chanInt)
 go func() {
  for {
   //不使用ok会goroutine泄漏
   //res := <-chanInt
   res,ok := <-chanInt
   if !ok {
                 break
            }
   fmt.Println(res)
  }
 }()
 chanInt <- 1
 chanInt <- 1
}

输出:

1
1
  • 给通道的接收加上二值,ok 代表通道是否正常,如果是关闭则为false
  • 可以删掉那段逻辑试试,会输出1 2 0 0 0这样的数列,因为关闭是需要时间的,而循环接收关闭的通道拿到的是0
  • 关于goroutine泄漏稍后会讲到

应该先发送还是先接收

假如我们调换一下位置,把接收放外面,写入放里面会发生什么

func multipleDeathLock2() {
 chanInt := make(chan int)
 defer close(chanInt)
 go func() {
  chanInt <- 1
  chanInt <- 2
 }()
 for {
  res, ok := <-chanInt
  if !ok {
   break
  }
  fmt.Println(res)
 }
}

输出死锁

1
2
fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan receive]:
main.multipleDeathLock2()
  • 出现上面的结果是因为for循环一直在获取通道中的值,但是在读取完1 2后,通道中没有新的值传入,这样接收者就阻塞了。
  • 为什么先接收再发送可以,因为发送提前结束后会触发函数的defer自动关闭通道
  • 所以我们应该总是先接收后发送,并由发送端来关闭

goroutine 泄漏

goroutine 终止的场景有三个:

  • 当一个 goroutine 完成了它的工作
  • 由于发生了没有处理的错误
  • 有其他的协程告诉它终止

当三个条件都没有满足,goroutine 就会一直运行下去

func goroutineLeak() {
 chanInt := make(chan int)
 defer close(chanInt)
 go func() {
  for {
            res := <-chanInt
   //res,ok := <-chanInt
   //if !ok {
            //     break
            //}
   fmt.Println(res)
  }
 }()
 chanInt <- 1
 chanInt <- 1
}
  • 上面的goroutineLeak()函数结束后触发defer close(chanInt)关闭了通道
  • 但是匿名函数中goroutine并没有关闭,而是一直在循环取值,并且取到是的关闭后的通道值(这里是int的默认值 0)
  • goroutine会永远运行下去,如果以后再次使用又会出现新的泄漏!导致内存、cpu占用越来越多

输出,如果程序不停止就会一直输出0

1
1
0
0
0
...

假如不关闭且外部没有写入值,那接收处就会永远阻塞在那里,连输出都不会有

func goroutineLeakNoClosed() {
 chanInt := make(chan int)
 go func() {
  for {
            res := <-chanInt
   fmt.Println(res)
  }
 }()
}
  • 无任何输出的阻塞
  • 换成写入也是一样的
  • 如果是有缓冲的通道,换成已满的通道写没有读;或者换成向空的通道读没有写也是同样的情况
  • 除了阻塞,goroutine进入死循环也是泄露的原因

如何发现泄露

使用 golang 自带的pprof监控工具,可以发现内存上涨情况,这个后续会讲

还可以监控进程的内存使用情况,比如prometheus提供的process-exporter

如果你有内存泄露/goroutine 泄露代码扫描的工具,欢迎留言,感恩!

小结

今天我们学习了一些细节,但是相当重要的知识点,也是未来面试高频问题哦!

  • 如果是信号通知,应该保证一一对应,不然会死锁
  • 除了信号通知外,通常我们使用循环处理通道,在工作中不断的处理数据
  • 应该总是先接收后发送,并由发送端来关闭,不然容易死锁或者泄露
  • 在接收处,应该对通道是否关闭做好判断,已关闭应该退出接收,不然会泄露
  • 小心 goroutine 泄漏,应该在通道关闭的时候及时检查通道并退出
  • 除了阻塞,goroutine进入死循环也是泄露的原因

往期精彩回顾

后续文章更新请点击阅读原文跳转开源书

(点击上方卡片关注我持续更新优质文章)

本文分享自微信公众号 - roseduan写字的地方(rose_duan)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-07-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Go 笔记之如何防止 goroutine 泄露

    Go 的并发模型与其他语言不同,虽说它简化了并发程序的开发难度,但如果不了解使用方法,常常会遇到 goroutine 泄露的问题。虽然 goroutine 是轻...

    波罗学
  • 6.824 2020 视频笔记二:RPC和线程

    MIT 今年终于主动在 Youtube 上放出了随堂视频资料,之前跟过一半这门课,今年打算刷一下视频,写写随堂笔记。该课程以分布式基础理论:容错、备份、一致性为...

    青藤木鸟
  • 深度阅读之《Concurrency in Go》

    很多朋友可能都知道,年前我从滴滴跑路,来了字节跳动,并且很快就写了篇传播甚广的弱智找 bug 文章:《“���”引发的线上事故》,之后就再也没动静了……

    梦醒人间
  • Go sync.Pool 浅析

    sync.Pool 应该是 Go 里面明星级别的数据结构,有很多优秀的文章都在介绍这个结构,本篇文章简单剖析下 sync.Pool。不过说实话 sync.Poo...

    haohongfan
  • golang面试

    Michel_Rolle
  • Gopher 2019 Go并发编程的分享

    昨天参加了 Gopher China 2019 大会,分享了《Go并发编程实践》的主题,在这一篇博客中总结一下。

    李海彬
  • 如何使用 Go 语言写游戏服务器?

    之前先后用Erlang,nodejs做过tcp,http的游戏服务器。接触了golang一两个月(纯新手),想在最近的tcp网游项目中使用,但又担心以下问题: ...

    李海彬
  • 如何使用 Go 语言写游戏服务器?

    之前先后用Erlang,nodejs做过tcp,http的游戏服务器。接触了golang一两个月(纯新手),想在最近的tcp网游项目中使用,但又担心以下问题: ...

    李海彬
  • 如何使用 Go 语言写游戏服务器?

    之前先后用Erlang,nodejs做过tcp,http的游戏服务器。接触了golang一两个月(纯新手),想在最近的tcp网游项目中使用,但又担心以下问题: ...

    李海彬
  • 实战Go内存泄露

    最近解决了我们项目中的一个内存泄露问题,事实再次证明pprof是一个好工具,但掌握好工具的正确用法,才能发挥好工具的威力,不然就算你手里有屠龙刀,也成不了天下第...

    大彬
  • 无人值守的自动 dump(一)

    Go 项目做的比较大(主要说代码多,参与人多)之后,可能会遇到类似下面这样的问题:

    梦醒人间
  • 谈谈go语言编程的并发安全

    问题起因 在分布式存储开源项目 Weed-FS 中, 我发现了一个地方非并发安全(not concurrency-safety), 所以提交了一个 Weed-F...

    李海彬
  • 一顿操作猛如虎,一看结果还是 0,Rust 能避免 Go 的 Bug?

    早些时候我看到这样一条新闻,在谈到Linux内核与Rust的关系时,谷歌曾表示Rust现在已经准备好加入C语言,成为实现内核的实用语言。它可以帮助减少特权代码中...

    MikeLoveRust
  • 6.824 2020 视频笔记五:Go Concurrency

    MIT 今年终于主动在 Youtube 上放出了随堂视频资料,之前跟过一半这门课,今年打算刷一下视频,写写随堂笔记。该课程以分布式基础理论:容错、备份、一致性为...

    青藤木鸟
  • 万级K8s集群背后etcd稳定性及性能优化实践

    随着腾讯自研上云及公有云用户的迅速增长,一方面,腾讯云容器服务TKE服务数量和核数大幅增长, 另一方面我们提供的容器服务类型(TKE托管及独立集群、EKS弹性集...

    腾讯云原生
  • 规避 Go 中的常见并发 bug

    在Understanding Real-World Concurrency Bugs in Go这篇论文中,几名研究人员分析了常见的Go并发bug,并在最流行的...

    simpleapples
  • go pprof实战

    1 为什么要进行性能优化 1.1 哪些情况需要进行性能优化 其实关于性能优化的主题,网上已经讨论很多次,这里谈一下我的理解,那么其实核心就是2个点: 服务一直...

    QQ音乐技术团队
  • 无辜的goroutine

    简介: 本文主要是针对一些对于goroutine的“指控”提出我自己的看法,特别是轩脉刃的一篇博客文章《论go语言中goroutine的使用》提出了gorout...

    李海彬
  • 无辜的goroutine

    简介: 本文主要是针对一些对于goroutine的“指控”提出我自己的看法,特别是轩脉刃的一篇博客文章《论go语言中goroutine的使用》提出了gorout...

    李海彬

扫码关注云+社区

领取腾讯云代金券