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

开发 运维
今天谈的这一篇呢,是Uber工程师针对Uber的众多的Go代码做的分析。

今天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也是很常见的数据竞争的原因。

责任编辑:张燕妮 来源: 鸟窝
相关推荐

2012-02-02 15:57:09

HibernateJava

2009-11-25 13:33:39

并发

2022-09-13 13:49:05

数据库隔离

2021-02-26 13:50:37

Java并发代码

2021-07-01 19:31:50

并发JavaCPU

2016-04-08 14:32:32

全栈工程师世界

2017-02-22 14:30:30

IT存储工程师公有云

2016-11-04 13:30:07

Python运维工程师

2021-01-20 10:30:04

大数据大数据开发

2009-09-03 09:01:38

2012-10-18 15:10:51

前端工程师面试题WEB开发

2021-06-04 14:28:07

协程线程Android开发

2023-10-23 08:12:34

并发问题有锁和无锁

2021-06-03 14:08:03

开发技能代码

2023-10-20 08:01:08

2009-02-26 10:57:52

CCNA网络工程师认证考试

2010-04-12 16:24:15

Oracle表查询

2009-04-13 11:50:14

经验交流职业分析面试

2009-10-09 23:03:45

2017-12-28 15:56:41

FastDFS排查并发
点赞
收藏

51CTO技术栈公众号