有几个学生研究归纳了go编程中的并发bugs，发表了一篇（英文）论文。论文原文地址：https://songlh.github.io/paper/go-study.pdf
在此做一个笔记，便于查阅。
文章以六个产品级go应用作为研究对象：Docker、Kubernetes、etcd、gRPC、CockroachDB、BoltDB，总共研究了这些应用中的171个bug，研究它们的根本原因，并重现这些bugs，以及检查它们的修复补丁。最后用两个现有go并发bug检测器测试了这些bug。
文章试图回答一个问题：对于两种线程/协程间通信机制，消息传递机制和共享内存机制，哪个更不容易出错？
文章从两个维度对bug进行了分类，bug原因（对共享内存的误用、对消息传递的误用）和bug表现（阻塞性bug、非阻塞性bug）。
研究结果及提交日志可以在以下地址查阅：https://github.com/system-pclub/go-concurrency-bugs
many concurrency bugs are caused by the mixed usage of message passing and other new semantics and new libraries in Go, which can easily be overlooked but hard to detect.
背景
-
使用共享内存实现同步
Go支持协程间共享内存，提供了多种传统的同步手段，如锁（Mutex）、读写锁（RWMutex）、条件变量（Cond）、原子读写（atomic）。go的RWMutex实现与C中的pthread_rwlock_t不同，go中的写锁请求优先级高于读锁。
go中还有一些新特性，Once保证一个函数只执行一次：使用 Once.Do(f) 方法，即使这一语句被多个协程调用了多次，也只有第一次的时候，函数f会被执行。
和C中的pthread_join类似，go使用WaitGroup来实现等待协程对其他协程的等待。
-
使用消息传递实现同步
channel（chan）是go的新特性，学习go语言编程的都应该熟悉了。channel分有缓冲和无缓冲两种（buffered and unbuffered）。
使用select可以从多路channel中进行选择。当有多路case有效时，select会从中随机选择一个去执行，这种随机性可能会造成bug。
Go引入了几种新机制来简化协程间的交互，如用context携带数据传递在不同协程之间，还有Pipe可在读协程和写协程之间传递流式数据。这两种都是新的消息传递机制，不注意的话可能引起新的并发bug。
Go并发模型
在研究并发bug前，文章先研究了go中的并发模型。
首先统计了那几个应用中创建gorutine的（静态）语句数量（位置数量），如下表：
文章觉得喜欢用匿名函数创建gorutine的多些（除了kubernetes和BoltDB），另外还发现C语言版gRPC比go语言版更少创建线程语句。
然后，文章还统计了各种同步机制的使用比例，如下图：
从中可以看出，共享内存机制的锁还是用得最多啊！
同时，这些机制的使用比例，随着项目时间推进，是否有什么变化趋势的？似乎没有明显变化，如下截图：
Bug分类
分类如下：
从数值看，阻塞性bug和非阻塞性bug出现数量差不多。
（笔者注：对于原因而言，从数值上看使用共享内存的造成bug比较多，但是这里只统计了绝对值，没有和前面共享机制的使用量结合起来考虑比例，似乎不大妥当。）
对于这些bug，文章作者使用相应有bug的版本，根据bug报告中的操作尝试重现这些bug，结果发现并发bug是很难重现的。从而这些bug存在时间都比较长，而一旦被发现，一般会比较快地得到解决。bug生存时间统计如下：
Bug原因分析
1、阻塞性bug
统计如下：
具体分析
（1）对共享内存保护的失误：
Mutex：28个阻塞性bug由对锁的不当使用造成，包括重复锁、以冲突的顺序申请锁、忘记解锁。这些bug都是传统bug，文章觉得传统的死锁检测算法应该能检测出这类bug。
RWMutex：前面提到过，go中的写锁优先级高。这种实现机制可以造成如下bug：协程A对同一个RWMutex申请两次读锁，但在这两次申请中间，协程B申请写锁。此时，由于A已经持有了一个读锁，而写锁又是排他性的，所以B被阻塞。然后，A第二次申请读锁时，由于B的写锁优先级高，所以A的读锁必须排在B的写锁请求之后，导致A被阻塞。从而发生了死锁。
统计中有5个bug是由这个原因造成。由于在C语言中这种情况不会造成死锁，所以参考C语言类似机制在Go中写这样的代码，容易导致这样的bug。
Wait：3个阻塞性bug归因于等待操作无法继续。跟Mutex和RWMutex不同，这里并不涉及循环等待。有两个bug是这样的：Cond被用来保护共享内存访问，其中一个协程调用了Cond.Wait()，但是在这之后却没有别的协程调用Cond.Signal()（或Cond.Broadcast()）。
另一个bug，Docker#25384，如下图所示，使用了一个共享的WaitGroup变量，造成bug主要是Wait()放在了错误的地方即第7行，修复bug只需要把Wait()挪到图中的第8行（循环外）。
（2）对消息传递的误用
Channel：对通过channel传递消息的错误使用导致了29个阻塞性bug。很多都跟发送和接收的错配有关。如下图所示，在使用第2行代码初始化channel的情况下，在子协程执行到第6行代码前，如果超时时间到了，或者子协程执行到第6行时，select的两个case同时可用，由于select的随机性而跑到了超时的那个case，就会导致finishReq函数返回，从而子协程阻塞。这个问题的修复方法是将channel定义为缓冲channel，这样无论何种情况子协程都不会阻塞住。
当组合使用go特定类库时，channel的创建和协程阻塞有可能被埋在了类库的调用之中。如下图所示，行1创建了一个新的context对象 hcancel，同时一个新的协程被创建，消息可以通过hcancel的channel传递到新协程。如果在行4 timeout大于0，另一个context对象在行5被创建，并且hcancel指向了新的对象。之后，将无法向协程所关联的旧对象发送消息，旧对象也没法被关闭。这个问题的避免方法是，避免创建额外的context对象。
Channel和其他的阻塞特性：有16个bugs，其中一个协程阻塞在Channel操作，而别的协程阻塞在锁或等待上。如下图，协程1在发送消息到ch时阻塞了，而同时协程2却被m.Lock()阻塞。解决方案是对协程1使用具有default分支的select来确保ch不再阻塞。
消息库函数：go提供了几种传递消息和数据的库，如Pipe。对这些的不正确使用也会造成bug。例如，和Channel类似，如果一个Pipe未关闭，Pipe的两端一个伙伴挂了，另一个伙伴等着读或写数据，那这是等着读或写数据的伙伴就被阻塞住了。类似的bug有4个。
最后，关于阻塞性bug，文章认为消息传递机制更容易造成更多类型的bug。
2、非阻塞性bug
统计如下：
（1）对共享内存的保护失败
已有很多研究发现，未保护共享内存或保护错误是造成数据竞争或其他非阻塞性bug的主要原因。本文也发现80%非阻塞性bug都归因于未保护或错误地保护共享内存。但go中的情况和传统编程语言的情况也并非完全相同。
传统bug：超过一半非阻塞性bug都是由于传统问题造成的，就跟在Java、C这些编程语言中一样，如原子操作的破坏、顺序混乱、数据竞争。有几个bug是对go新特性的不够理解造成的，如：Docker#22985 和 CockroachDB#6111 是由于将一个变量的引用通过Channel在不同协程间传递，从而造成了共享变量的竞争状态。
匿名函数：Go语言中在一个函数前加go关键字就可以启动协程，这个函数是可以没有名字的（匿名）。在匿名函数之前定义的所有局部变量，在匿名函数中都是可见的。不幸的是，由于开发者可能不够注意对这些在不同协程中的共享变量做保护，从而可能容易导致数据竞争的bug。有11个bug就是这种类型，其中9个是父协程和子协程之间的数据竞争，2个是两个子协程之间的数据竞争。如下图的一个例子，含bug的版本中，变量i在父协程和子协程之间共享了，开发者想要得到不同的i值所生成的apiVersion，但是如果在父协程的for循环结束后子协程才运行起来，那所有的apiVersion都将等于”v1.21”。 解决方案就是将i作为参数传递到子协程中，此时传递的是i的拷贝。
WaitGroup的误用：使用WaitGroup的一个基本准则是，Add必须在Wait之前执行。有6个bug是因为违反了这条准则。如下图所示，这是etcd中的一个bug，这里是无法保证func1中行8的Add一定在func2中行5的Wait之前执行的。解决方案就是将Add操作遇到行6的位置，保证要么Add在Wait之前执行，要么根本不会执行到idle这个case。
特定库函数：go中有些类库的变量是隐式在多协程中共享的。如context就被设计为可以被多个关联协程访问。etcd#7816就是因为在多个协程中竞争使用一个context对象的一个字符串字段导致的。
另一个例子是testing包。测试函数只有一个testing.T类型的变量，这个变量用于传递测试状态如error何日志。有3个bug就是在测试函数以及测试函数内启动的子协程之间竞争使用testing.T变量导致。
（2）消息传递中的错误
channel的误用：前面也提到过，channel的使用需要遵循一定的规则，否则就会引起一些bug。如下图所示（Docker#24007），可能有多个协程会运行到这段代码，其中可能有多个跑到了select的default分支，导致对channel的多次关闭，从而引发panic。这种情况，可以使用Once.Do将关闭channel的语句包起来，保证它只会执行一次。
还有一种类型是将channel和select一起使用，当select收到多个case的消息时，是没办法保证会执行哪一个的，这种非确定性的选择，导致了3个bug。下图是一个例子，其中f函数执行耗时操作，当它执行完之后，stopCh的消息和ticker有可能同时到达，此时并不一定会执行到11行return语句，也有可能执行到case <- ticker 这里，从而继续循环，f()没必要地多执行了一次。这种情况下，应该在f()执行的前后都判断一下是否该退出循环。
特定库函数：一些库函数内部会使用channel，也可能导致非阻塞性bug。下图是一个与time包有关的bug。开发者想实现的是，要么收到Done信号，要么超时，然后再返回。但是含bug的版本先创建了超时时间为0的timer，然后再判断参数dur是否大于0 ，大于0的话修改timer。但是，当dur为0的情况下，timer实际上一开始就被设置为有信号了，可能导致函数过早返回。解决方案是不要让timer过早创建。
非阻塞性bug的检测
Go提供了数据竞争检测，在build的时候使用 -race 标志即可启用。
文章的一些结论是，消息传递机制也容易造成bug，情况并不比共享内存机制好。消息传递机制更多地会造成一些阻塞性bug，比较少造成非阻塞性bug，而且可以用于解决由于共享内存导致的非阻塞性bug。
关于bug检测，目前很多在传统语言中针对共享内存的检测算法，在go中也是适用的，但是针对go的消息传递机制所引起bug的检测，还需研究。
有疑问加站长微信联系（非本文作者）
