Understanding Real-World Concurrency Bugs in Go这篇论文中,几名研究人员分析了常见的Go并发bug,并在最流行的几个Go开源项目中进行了验证。本文梳理了论文中提到的常见的bug并给出解决方法的分析。

论文中对bugs进行了分类,分为阻塞式和非阻塞式两种:
阻塞式:goroutine发生阻塞无法继续执行(例如死锁)
非阻塞式:不会阻塞执行,但存在潜在的数据冲突(例如并发写)

阻塞式bug

阻塞式bug发生的根因有两种,一种是共享内存(例如卡在了意图保护共享内存的锁操作上),一种是消息传递(比如等待chan)。同时研究发现共享内存和消息传递导致的bug数量不想上下,但是共享这种方法的使用量比消息传递使用的更频繁,所以也得出了共享内存方式更不容易导致bug的结论。

读写锁优先级导致的死锁

在Go中的写锁优先级高于读锁优先级,假设一个goroutine(goroutine A)连续获取两次读锁,而另一个goroutine(goroutine B)在gouroutine A两次获取读锁中间获取了写锁,就会导致死锁的发生。论文中没有针对这个bug给出示例代码,我写了一个简单的代码示意一下。

1
2
3
4
5
6
7
8
func gouroutine1() {
m.RLock()
m.RLock()
}

func gouroutine2() {
m.WLock()
}

f1和f2都在goroutine中执行,当f1执行完第一个l.RLock()语句后,假设这时f2的m.WLock执行,由于写锁是排它的,WLock本身被f1的第一个m.RLock()阻塞,写锁操作本身又会阻塞f1中的第二个m.RLock

WaitGroup误用导致的死锁

这种情况就是比较典型的WaitGroup的误用了,提前执行group.Wait()会导致部分group.Done()无法执行到,进而导致程序被阻塞。

1
2
3
4
5
6
7
8
9
var group sync.WaitGroup
group.Add(len(pm.plugins))
for _, p := range pm.plugins {
go func(p *plugin) {
defer group.Done()
}
group.Wait() // blocked
}
// group.Wait() should be here

for循环内的group.Wait()执行到的时候,循环内的部分goroutine还没有被创建出来,其中的group.Done()也就永远没法执行到,所以会导致永远阻塞在这一句,正确的写法是将group.Wait()移到for循环外。

Channel的误用

Channel是go支持并发的一个非常重要的特性,Channel虽然在很多场景下非常解决问题,但是误用也是不容易发现的。

1
2
3
4
5
6
7
8
9
10
11
12
13
func goroutine1() {
m.Lock()
ch <- request // blocked
m.Unlock()
}

func goroutine2() {
for {
m.Lock() // 阻塞
m.Unlock()
request <- ch
}
}

这段代码的业务语义是goroutine1会通过ch接收goroutine2发送的消息,但是当goroutine1执行到ch <- request时候会阻塞并等待ch,此时由于goroutine1没有释放锁,goroutine2的m.Lock()也会阻塞,形成死锁。

特殊库的误用

1
2
3
4
hctx, hcancel := context.WithCancel(ctx)
if timeout > 0 {
hctx, hcancel = context.WithTimeout(ctx, timeout)
}

除了显式的使用channel,go提供了一些lib来在goroutine之间传递消息,上面代码在执行hctx, hcancel := context.WithCancel(ctx)时会创建一个goroutine出来,而当timeout>0时又回创建新的channel赋给同一个变量hcancel,这会导致第一行创建出的channel不会被关闭,也不能再给这个channel发消息。

非阻塞式bug

和阻塞式bug类似,非阻塞式bug也由共享内存和消息传递引起:当试图保护一个共享变量失败时候,或消息传递使用不当时候,都可能造成非阻塞式的bug。

匿名函数

虽然论文中将这一类错误归结为匿名函数的不正确使用,但实际上产生这类bug的原因是工程师忽略了实际上在跨goroutine共享的变量。

1
2
3
4
5
6
for i := 17; i <= 21; i++ { // write
go func() { /* Create a new goroutine */
apiVersion := fmt.Sprintf("v1.%d", i) // read
...
}()
}

如这段代码(也经常出现在面试中),由于变量i在匿名函数构建出的goroutine和主goroutine共享,又不能保证goroutine什么时候执行,所以goroutine中拿到的i并不确定(大概率这几个循环创建出的goroutine拿到的都是21)。

WaitGroup的误用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
func (p *peer) send() {
p.mu.Lock()
defer p.mu.Unlock()
switch p.status {
case idle:
go func() {
p.wg.Add(1)
...
p.wg.Done()
}()
case stopped:
}
}

func (p * peer) stop() {
p.mu.Lock()
p.status = stopped
p.mu.Unlock()
p.wg.Wait()
}

上面这段代码中,由于不能保证send方法的goroutine什么时候执行,所以可能导致stop函数的p.wg.Wait()在send函数的p.wg.Add(1)之前执行。

特殊库的误用

诸如context这样被设计会在多个goroutine间传递数据的库,在使用时也需要特别注意,可能会导致数据竞争。

Channel的误用

1
2
3
4
5
select {
case <- c.closed:
default:
close(c.closed)
}

由于default语句可能被多次触发,导致一个channel可能被多次关闭,进而造成panic。

1
2
3
4
5
6
7
8
ticker := time.NewTicker()
for{
f() // heavy function
select {
case <- stopCh: return
case <- ticker:
}
}

对于上面这段代码,当f是一个耗时函数时,很可能出现一次for循环后stopCh和ticker两个case同时满足,这时是没法确认先进哪个case的。

特殊库的误用

1
2
3
4
5
6
7
8
9
10
timer := time.NewTimer(0)
if dur > 0 {
timer = time.NewTimer(dur)
}

select {
case <- timer.C:
case <- ctx.Done():
return nil
}

上面这段代码中,第一行创建的timer由于超时时间是0,所以会立刻触发select中的第一个case,导致和期望不符合的行为。

总结

Go的特性使得线程的创建和数据传递都非常容易,但是容易的背后线程间通信的那些坑依然是存在的,论文认为go的消息传递机制会导致更多的bug出现。在我看来,go的消息传递机制相比于传统的共享内存机制,相当于多了一层逻辑层面的封装,这种特性有时会让传统的多线程编程经验不能直接发挥价值,但是只要把握住底层的机制,可以很快积累基于go的语言特性的并发编程经验。