Go带来了新的并发原语和并发模式(其实也不太新),如果没有深入了解这些特性,一样会写出并发bug。
在 Understanding Real-World Concurrency Bugs in Go 这篇论文里,作者系统地分析了6个流行的Go项目(Docker、Kubernetes、gRPC-go、etcd、CockroachDB、 BoltD)和其中171个并发bug,通过这些分析我们可以加深对Go的并发模型的理解,从而产出更好、更可靠的代码。
Our study shows that it is as easy to make concurrency bugs with message passing as with shared memory,sometimes even more.
我们的研究表明,消息传递和共享内存一样、有时甚至更容易写出并发错误。
例如下面是k8s的一个bug,finishReq
创建了一个子协程来执行fn
然后通过select
等待子协程完成或超时:
func finishReq(timeout time.Duration) r ob {
ch :=make(chanob)
// ch :=make(chanob, 1) // 修复方案
go func() {
result := fn()
ch <- result // 阻塞
}
select {
case
result = <- ch
return result
case <- time.After(timeout)
return nil
}
}
}
如果超时先发生,或者子协程和超时同时发生但go运行时选择了超时分支(非确定性),子协程就会永远阻塞。
Go并发模式使用情况
这一节分析了6个项目里goroutine、并发原语的使用情况。
匿名函数的goroutine使用比普通函数要多,基本每1~5千行代码创建一个goroutine。
虽然Go鼓励消息传递,但是在这些大项目里,共享内存的使用比消息传递要多,Mutex基本在channel的两倍以上。
Bug分类
这篇论文里,按两个维度对bug进行分类:
- 行为:阻塞和非阻塞,阻塞bug指goroutine意外地阻塞无法继续执行的情况(例如死锁),非阻塞bug通常是数据冲突
- 原因:共享内存和消息传递,因为用了这两种技术之一导致的bug
可以看到,共享内存其实导致了更多的bug。
阻塞bug
消息传递和共享内存导致的阻塞bug几乎一样多,而且消息传递的阻塞bug都和Go的消息传递语义例如channel有关,消息传递和共享内存一起使用的时候会很难发现bug。
例如Docker错误使用WaitGroup
导致阻塞:
var group sync.WaitGroup
group.Add(len(pm.plugins))
for_, p := range pm.plugins {
go func(p *plugin) {
defer group.Done()
}
group.Wait() // 阻塞
}
// 应该在这里group.Wait()
错误使用channel和mutex导致阻塞:
func goroutine1() {
m.Lock()
ch <- request // 阻塞
m.Unlock()
}
func goroutine2() {
for{
m.Lock() // 阻塞
m.Unlock()
request <- ch
}
}
非阻塞bug
共享内存导致更多的非阻塞bug,几乎是消息传递的8倍。
例如在下面这段代码里,每当ticker
触发时执行一次f()
,通过stopCh
退出循环:
ticker := time.NewTicker()
for {
f()
select {
case <- stopCh
return
case <- ticker
}
}
但是select是非确定性的,stopCh
和ticker
同时发生时,不一定会执行stopChan
的分支,正确做法是先检查一次stopCh
:
ticker := time.NewTicker()
for {
select{
case <- stopCh:
return
default:
}
f()
select {
case <- stopCh:
return
case <- ticker:
}
}
参考
- system-pclub/go-concurrency-bugs:论文数据集,包含各项目真实bug代码和修复,是个非常好的学习资源。
- Understanding Real-World Concurrency Bugs in Go:论文本体
有疑问加站长微信联系(非本文作者)