Uber工程师对真实世界并发问题的研究

今天Uber工程师放出一篇论文(A Study of Real-World Data Races in Golang]( https://arxiv.org/abs/2204.00764))，作者是Uber的工程师Milind Chabbi和Murali Krishna Ramanathan，他们负责使用Go内建的data race detector在Uber内的落地，经过6个多月的研究分析，他们将data race detector成功落地，并基于对多个项目的分析，得出了一些有趣的结论。

我们知道，Go是Uber公司的主打编程语言。他们对Uber的2100个不同的微服务，4600万行Go代码的分析，发现了超过2000个的有数据竞争的bug, 修复了其中的1000多个，剩余的正在分析修复中。

谈起真实世界中的Go并发Bug,其实2019年我们华人学者的 Understanding Real-World Concurrency Bugs in Go 论文可以说是开山之作，首次全面系统地分析了几个流行的大型Go项目的并发bug。今天谈的这一篇呢，是Uber工程师针对Uber的众多的Go代码做的分析。我猜他们可能是类似国内工程效能部的同学，所以这篇论文有一半的篇幅介绍Go data race detector是怎么落地的，这个我们就不详细讲了，这篇论文的另一半是基于对data race的分析，罗列出了常见的出现data race的场景，对我们Gopher同学来说，很有学习的意义，所以我晚上好好拜读了一下这篇论文，做一总结和摘要。

作为一个大厂，肯定不止一种开发语言，作者对Uber线上个编程语言(go、java、nodejs、python)进行分析，可以看到：

1. 相比较Java， 在Go语言中会更多的使用并发处理
2. 同一个进程中，nodejs平均会启动16个线程，python会启动16-32个线程，java进程一般启动128-1024个线程，10%的Java程序启动4096个线程，7%的java程序启动8192个线程。Go程序一般启动1024-4096个goroutine,6%的Go程序启动8192个goroutine(原文是8102，我认为是一个笔误)，最大13万个。

可以看到Go程序会比其它语言有更多的并发单元，更多的并发单元意味着存在着更多的并发bug。Uber代码库中都有哪些类的并发bug呢？

下面的介绍会很多的使用数据竞争概念(data race)，它是并发编程中常见的概念，有数据竞争，意味着有多个并发单元对同一个数据资源有并发的读写，至少有一个写，有可能会导致并发问题。

透明地引用捕获 (Transparent Capture-by-Reference)

直接翻译过来你可能觉得不知所云。Transparent是指没有显示的声明或者定义，就直接引用某些变量，很容易导致数据竞争。通过例子更容易理解。这是一大类，我们分成小类逐一介绍。

循环变量的捕获

不得不说，这也是我最常犯的错误。虽然明明知道会有这样的问题，但是在开发的过程中，总是无意的犯这样的错误。

for _ , job := range jobs {
 go func () {
   ProcessJob ( job )
 }()
 } // end for

比如这个简单的例子,job是索引变量，循环中启动了一个goroutine处理这个job。job变量就透明地被这个goroutine引用。

循环变量是唯一的，意味着启动的这个goroutine,有可能处理的都是同一个job,而并不是期望的没有一个job。

这个例子还很明显，有时候循环体内特别复杂，可能并不像这个例子那么容易发现。

err变量被捕获

Go允许返回值赋值给多个变量，通常其中一个变量是error。 x, err := m, n 意味着声明和定义left hand side(LHS)变量，如果变量还没有声明过的话，那就是定义了一个新的变量，但是如果变量已声明过得话，那就是对已有变量的重新赋值。

下面这个例子，y,z的赋值时，会对同一个err进行写操作，也可能会导致数据竞争，产生并发问题。

x , err := Foo ()
if err != nil {
...
}

go func () {
 y , err := Bar ()
  if err != nil {
  ...
  }
}()

z , err := Baz ()
if err != nil {
...
}

捕获命名的返回值

下面这个例子定义了一个命名的返回值 result 。可以看到 ... = result （读操作）和 return 20 (写操作)有数据竞争的问题，虽然 return 20 你并没有看到对result的赋值。

func NamedReturnCallee () ( result int) {
  result =10
  if ... {
    return // this has the effect of " return 10"
  }
  go func () {
   ... = result // read result
  }()
  return20 // this is equivalent to result =20
}

func Caller () {
 retVal := NamedReturnCallee ()
}

defer 也会有类似的效果,下面这段代码对err有数据竞争问题。

func Redeem ( request Entity ) ( resp Response , err error )
{
 defer func () {
  resp , err = c . Foo ( request , err )
 }()
 err = CheckRequest ( request )
 ... // err check but no return
 go func () {
  ProcessRequest ( request , err != nil )
 }()
 return // the defer function runs after here
 }

Slice相关的数据竞争

下面这个例子， safeAppend 使用锁对 myResults 进行了保护，但是在每次循环调用 (uuid, myResults) 并没有读保护，也会有竞争问题，而且不容易发现。

func ProcessAll ( uuids [] string ) {
 var myResults [] string
 var mutex sync . Mutex
 safeAppend := func ( res string ) {
 mutex.Lock ()
  myResults = append ( myResults , res )
 mutex.Unlock ()
 }

 for _ , uuid := range uuids {
 go func ( id string , results [] string ) {
 res := Foo ( id )
 safeAppend ( res )
  }( uuid , myResults ) // slice read without holding lock
 }
 ...
 }

非线程安全的map

这个很常见了，几乎每个Gopher都曾犯过，犯过才意识到Go内建的map对象并不是线程安全的，需要加锁或者使用sync.Map等其它并发原语。

func processOrders ( uuids [] string ) error {
var errMap = make ( map [ string ] error )
for _ , uuid := range uuids {
go func ( uuid string ) {
orderHandle , err := GetOrder ( uuid )
if err != nil {
▶ errMap [ uuid ] = err
return
}
...
}( uuid )
return combineErrors ( errMap )
}

传值和传引用的误用

Go标准库常见并发原语不允许在使用后Copy, go vet也能检查出来。比如下面的代码，两个goroutine想共享mutex,需要传递 &mutex ,而不是 mutex 。

var a int
// CriticalSection receives a copy of mutex .
func CriticalSection ( m sync . Mutex ) {
m.Lock ()
 a ++
m.Unlock ()
}
func main () {
mutex := sync . Mutex {}
// passes a copy of m to A .
go CriticalSection ( mutex )
go CriticalSection ( mutex )
}

混用消息传递和共享内存两种并发方式

消息传递常用channel。下面的例子中，如果context因为超时或者主动cancel被取消的话，Start中的goroutine中的 f.ch <- 1 可能会被永远阻塞，导致goroutine泄露。

func ( f * Future ) Start () {
go func () {
resp , err := f.f () // invoke a registered function
 f.response = resp
 f.err = err
 f.ch <-1 // may block forever !
}()
}
func ( f * Future ) Wait ( ctx context . Context ) error {
select {
case <-f.ch :
return nil
case <- ctx.Done () :
 f.err = ErrCancelled
return ErrCancelled
}

并发测试

Go的 testing.T.Parallel() 为单元测试提供了并发能力，或者开发者自己写一些并发的测试程序测试代码逻辑，在这些并发测试中，也是有可能导致数据竞争的。不要以为测试不会有数据竞争问题。

不正确的锁调用

为写操作申请读锁

下面这个例子中， g.ready 是写操作，可是这个函数调用的是读锁。

func ( g * HealthGate ) updateGate () {
g.mutex.RLock ()
defer g.mutex.RUnlock ()
// ... several read - only operations ...
if ... {
 g.ready = true // Concurrent writes .
 g.gate.Accept () // More than one Accept () .
}

其它锁的问题

你会发现，大家经常犯的一个“弱智”的问题，就是Mutex只有Lock或者只有Unlock,或者两个Lock,这类问题本来你认为绝不会出现的，在现实中却经常能看到。

还有使用 atomic 进行原子写，但是却没有原子读。

我认为这里Uber工程师并没有全面详细的介绍使用锁常见的一些陷阱，推荐你学习极客时间中的 Go 并发编程实战课 课程，此课程详细介绍了每个并发原语的陷阱和死锁情况。

总结

总结一下，下表列出了基于语言类型统计的数据竞争bug数：

整体来看，锁的误用是最大的数据竞争的原因。并发访问slice和map也是很常见的数据竞争的原因。