经典面试题--golang交替打印cat、dog 以及出现死锁问题的分析

问题背景

一道经典面试题，如下：

1.  使用两个goroutine循环打印，cat，dog
2. 各打印5次

熟悉golang的同学，很容易写出如下代码:

func Pprint() {wg := sync.WaitGroup{}wg.Add(2)ch1, ch2 := make(chan struct{}), make(chan struct{})go func() {cnt := 0for {<-ch1fmt.Println("cat")cnt++ch2 <- struct{}{}if cnt == 5 {wg.Done()return}}}()go func() {cnt := 0for {<-ch2fmt.Println("do")cnt++ch1 <- struct{}{}if cnt == 5 {wg.Done()return}}}()ch1 <- struct{}{}wg.Wait()
}

这段代码，逻辑思路上没任何问题：

1. 构建两个channel当作通信的信号量，当某个信号量操作完成后通知另一个完成；
2. 通过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 := 0for {...省略...if cnt == 5 {wg.Done()fmt.Println("exit1")return}}}()go func() {cnt := 0for {...省略...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