问题背景
一道经典面试题,如下:
- 使用两个goroutine循环打印,cat,dog
- 各打印5次
熟悉golang的同学,很容易写出如下代码:
func Pprint() {
wg := sync.WaitGroup{}
wg.Add(2)
ch1, ch2 := make(chan struct{}), make(chan struct{})
go func() {
cnt := 0
for {
<-ch1
fmt.Println("cat")
cnt++
ch2 <- struct{}{}
if cnt == 5 {
wg.Done()
return
}
}
}()
go func() {
cnt := 0
for {
<-ch2
fmt.Println("do")
cnt++
ch1 <- struct{}{}
if cnt == 5 {
wg.Done()
return
}
}
}()
ch1 <- struct{}{}
wg.Wait()
}
这段代码,逻辑思路上没任何问题:
- 构建两个channel当作通信的信号量,当某个信号量操作完成后通知另一个完成;
- 通过sync.WaitGroup控制goroutine优雅退出。
问题
然而不幸的是,这段代码最终会出现死锁 panic:
正确打印五次后,却出现了死锁的panic,没有实现程序优雅退出。
那么原因是什么呢?
我们来分析死锁检测时报错堆栈信息,其中有一个关键信息引起了我们的注意
注意看第一行,上面报错信息的意思是:在func2协程(goroutine id是6),也就是我们代码中的第二个goroutine出现了因为 chan send阻塞导致的死锁。
到这里肯定就有同学困惑了,我都是刚好5次呀,而且两个channel ch1、ch2都是完全同步的。怎么就会因为chan send造成死锁呢???
继续看堆栈报错信息,还有一个关键的点,如下:
看到这里,更懵逼了吧。为什么第二个goroutine因为chan send和waitgroup产生了死锁???
我们不妨大胆猜测一下,是不是因为第二个gorouine因为某些原因无法正常退出,导致其wg.Done方法没法执行,因此系统检测到wg.Wait()所在的主协程永远无法执行完成,所以报出了deadlock panic。
下面我们在协程退出的地方加一些debug 日志来验证我们的猜想(重复代码省略了):
go func() {
cnt := 0
for {
...省略...
if cnt == 5 {
wg.Done()
fmt.Println("exit1")
return
}
}
}()
go func() {
cnt := 0
for {
...省略...
if cnt == 5 {
wg.Done()
fmt.Println("exit2")
return
}
}
}()
debug结果如下:
果然不出我们的猜测,只有第一个goroutine正常退出了,第二个goroutine都来不及退出,就被死锁检测到。
到这里我们也能大致知道原因了:第一个goroutine ch1正常退出之后,在第二个goroutine里,系统判断出 ch1 <- struct{}{} 这一句代码永远不会有接收者;又因为ch1是阻塞的channel,所以系统会认为这里会死锁,就抛出deadlock panic。
其实问题的关键点在于:ch1和ch2都是阻塞的channel
解决方案
最后,解决方案也很明了:
1. 方案一:使用带缓冲的channel
ch1, ch2 := make(chan struct{}, 1), make(chan struct{}, 1)
2. 方案二:使用select防止阻塞
总结
这个交替打印的问题本身并不复杂,但是却非常经典。考验我们对channel的理解,对并发编程技巧的掌握,以及控制协程优雅退出的能力。
日常coding中,需要清楚的了解业务的场景,然后考虑是否使用带缓冲的channel