介绍

共享数据竞争问题是并发系统中常见且难排查的问题.

什么是数据竞争?

当两个协程goroutine同时访问相同的共享变量,其中有一个执行了写操作,或两个都执行了写操作,就会出现数据竞争问题,导致数据异常.详情请参考Go内存模型详解:

如以下代码由于并发访问同一个map,存在数据冲突,一定概率导致数据异常,程序崩溃:

 package main
 import  "fmt"
func main(){
   c := make(chan bool)
   m := make(map[string]string)
   go func(){
      m["1"] = "a"  //运行时,这里有个协程对m进行写操作
      c <- true
   }()

   m["2"] = "b"  //主函数中也会对m进行写操作
   <-c  //根据通道先写后读的原则,这里会等待上面的go func执行完成
   for k, v := range m {
      fmt.Println(k, v)
   }
}
  

多次执行后出现,程序崩溃,提示map并发写错误:

怎么使用数据冲突检测器?

在go中,已经内置数据冲突检测器,直接在go命令行添加参数-race即可,如以下4种方式:

• go test -race mypkg //测试mypkg包
• go run -race main.go //带冲突检测调试运行源代码main.go
• go build -race main.go //带冲突检测编译源代码
• go install -race mypkg//安装mypkg包

冲突报告格式

检测到冲突时,会按照以下格式打印冲突报告,它包含堆栈跟踪信息,以及协程编号,如:

 ➜  dataRace git:(master) ✗ go run -race main.go==================WARNING: DATA RACE  //警告: 数据冲突Write at 0x00c000124180 by goroutine 7:  //普通协程写操作   runtime .mapassign_faststr()      /usr/local/go/src/runtime/map_faststr.go:202 +0x0  main.main.func1()      /Users/xb/gitlab/go/go_core_program/sync/dataRace/main.go:9 +0x5d
Previous write at 0x00c000124180 by main goroutine:  //主协程写操作  runtime.mapassign_faststr()      /usr/local/go/src/runtime/map_faststr.go:202 +0x0  main.main()      /Users/xb/gitlab/go/go_core_program/sync/dataRace/main.go:13 +0xcb
Goroutine 7 (running) created at:  main.main()      /Users/xb/gitlab/go/go_core_program/sync/dataRace/main.go:8 +0x9c==================2 b1 aFound 1 data race(s)  //找到一处数据冲突exit status 66  

运行选项

GORACE环境变量用于设置数据冲突检测选项, 在执行go程序前设置该值即生效,格式如下:

 GORACE="选项1=值1 选项2=值2 ..."
  

包含以下常用选项:

• log_path (default stderr): 日志文件前缀,冲突检测结果存入log_path. pid . 特别的,如果配置为stdout则输出到标准输出,配置为stderr则输出到错误输出
• exitcode (default 66): 检测到冲突时,程序的退出状态码,可以自定义,默认为66
• strip_path_prefix (default “”): 为了使报告简洁,该选项用于去除文件路径中这些前缀
• history_size (default 1): 每个协程goroutine内存访问历史大小为32K*2**history_size 个元素,增加该选项值可以避免在报告中出现”恢复堆栈失败错误”,但是会增加内存开销
• halt_on_error (default 0): 用于控制程序遇到数据竞争时,是否退出,默认不会退出,只打印错误信息.
• atexit_sleep_ms (default 1000): 在主线程goroutine中等待多少毫秒后退出,默认1秒

排除单元测试

当你使用-race参数构建时,go命令定义了更多的构建标记,当你运行冲突检测时,你可以使用这些标记排除代码和单元测试,比如:

 // +build !race   构建约束,用于排除有冲突的测试
package foo

// The test contains a data race. See issue 123. 
func TestFoo(t *testing.T) {
// ... 包含数据冲突
}

// The test fails under the race detector due to timeouts.
func TestBar(t *testing.T) {
// ... 包含冲突检测超时导致失败的代码
}

// The test takes too long under the race detector. 
func TestBaz(t *testing.T) {
// ...  包含在冲突检测下执行耗时太长的代码
}
  

使用冲突检测时注意事项

当使用go test -race做冲突检测时,检测器只会检测运行时的冲突,没有执行的代码块不会进行检测,如果你的单元测试是不完全覆盖,你需要使用go build -race构建一个完整的二进制包进行检测

典型数据冲突场景

• Race on loop counter 循环计数器冲突

 package main
import (
   "fmt"
   "sync"
)

func main() {
   //以下代码由于并发,同时获取值,存在冲突,所以i不会按照预期(012345)打印,比如打印55555,
   var wg sync.WaitGroup
   wg.Add(5)
   for i := 0; i < 5; i++ {
      go func() {
         fmt.Println(i) // Not the 'i' you are looking for.
         wg.Done()
      }()
   }
}
  

解决办法:对变量拷贝一份出来,新的变量指向不同的内存地址

 package main
import (
   "fmt"
   "sync"
)

func main() {
   //读取本地拷贝值j,与i指向不同的地址,解决冲突
   var wg sync.WaitGroup
   wg.Add(5)
   for i := 0; i < 5; i++ {
      go func(j int) {
         fmt.Println(j) // Good. Read local copy of the loop counter.
         wg.Done()
      }(i)
   }
   wg.Wait()
}
  

• 由于意外,共享了变量导致冲突

 
func ParallelWrite(data []byte) chan error {
   res := make(chan error, 2)
   f1, err := os.Create("file1")
   if err != nil {
      res <- err
   } else {
      go func() {
         // This err is shared with the main goroutine, 这里的err变量与主线程共享了
         // so the write races with the write below.
         _, err = f1.Write(data)
         res <- err
         f1.Close()
      }()
   }
   f2, err := os.Create("file2") // The second conflicting write to err.这里也在对err进行写操作
   if err != nil {
      res <- err
   } else {
      go func() {
         _, err = f2.Write(data)
         res <- err
         f2.Close()
      }()
   }
   return res
}  

解决办法: 重新分配err变量

 ...
_, err := f1.Write(data)
...
_, err := f2.Write(data)
...  

• 未加保护的全局变量

 
var service map[string] net .Addr
func RegisterService(name string, addr net.Addr) {
   service[name] = addr
}

func LookupService(name string) net.Addr {
   return service[name]
}
  

以上代码中,map在多个协程中并发中读写会导致冲突

解决方法: 使用互斥锁,保证同时只能读或者写

 
var (
   service   map[string]net.Addr
   serviceMu sync.Mutex
)

func RegisterService(name string, addr net.Addr) {
   serviceMu. Lock ()
   defer serviceMu.Unlock()
   service[name] = addr
}

func LookupService(name string) net.Addr {
   serviceMu.Lock()
   defer serviceMu.Unlock()
   return service[name]
}
  

• 使用了不受保护的基本数据类型

基本数据类型,如bool, int, int64等也存在数据冲突,这种问题难以排查,一般都是由于非原子的内存访问引起的,如:

 
type Watchdog struct{ last int64 }

func (w *Watchdog) KeepAlive() {
   w.last = time.Now().UnixNano() // First conflicting access. 写操作,与下面的读操作构成冲突
}

func (w *Watchdog) Start() {
   go func() {
      for {
         time.Sleep(time.Second)
         // Second conflicting access. 这里是读操作
         if w.last < time.Now().Add(-10*time.Second).UnixNano() {
            fmt.Println("No keepalives for 10 seconds. Dying.")
            os.Exit(1)
         }
      }
   }()
}
  

解决方法:使用通道或者互斥锁mutex, 也可以使用无锁的sync/atomic包,如:

 
type Watchdog struct{ last int64 }

func (w *Watchdog) KeepAlive() {
   atomic.StoreInt64(&w.last, time.Now().UnixNano()) //使用原子包存储方法
}

func (w *Watchdog) Start() {
   go func() {
      for {
         time.Sleep(time.Second)
         if atomic.LoadInt64(&w.last) < time.Now().Add(-10*time.Second).UnixNano() {  //使用原子包的读取方法
            fmt.Println("No keepalives for 10 seconds. Dying.")
            os.Exit(1)
         }
      }
   }()
}
  

• 未同步的发送和关闭操作,如:

 c := make(chan struct{}) // or buffered channel 这里也可以使用带缓冲的通道演示
// The race detector cannot derive the happens before relation
// for the following send and close operations. These two operations 下面的通道发送和关闭操作没有进行同步,导致冲突
// are unsynchronized and happen concurrently.
go func() { c <- struct{}{} }()
close(c)  

解决方法:通道关闭前,增加一个读取操作,完成同步

 
c := make(chan struct{}) // or buffered channel
go func() { c <- struct{}{} }()
<-c //根据Go语言内存模型,一个通道上写操作发生在读操作之前,所以这里读取时,写已经完成,完成了通道同步
close(c)  

• 单例模式场景也使用锁避免冲突

 package main
import (
   "fmt"
   "sync"
   "sync/atomic"
)

//定义单例结构体
type singleton struct {}

var(
   instance *singleton
   initialized uint32  //初始化标志,用于标识是否已经被初始化
   mu sync.Mutex  //互斥锁对象
)

func Instance() *singleton{
   if atomic.LoadUint32(&initialized)==1{  //如果实例已经初始化,直接返回
      return instance
   }

   //如果没有实例化,则用锁同步执行下面的代码,即同一时间只能有一个协程进入执行以下代码块
   mu.Lock()
   defer mu.Unlock()
   if instance==nil{
   defer atomic.StoreUint32(&initialized, 1)
   instance = &singleton{}
   }
   return instance
}


func main(){
   mySingleton := Instance()
   fmt.Printf("单例模式得到的对象:%v\n", mySingleton)
}
  

• 与单例模式类似的,用锁实现某个方法只调用一次(DoOnce)

 package main
import (
   "sync"
   "sync/atomic"
)

type Once struct{
   m sync.Mutex
   done uint32
}


//传入一个回调函数,保证只执行一次该回调函数
func(o *Once)Do(f func()){
   if atomic.LoadUint32(&o.done) == 1 {
      return
   }

   o.m.Lock()
   defer o.m.Unlock()
   if o.done == 0 {
      defer atomic.StoreUint32(&o.done, 1)
      f()  //回调函数
   }
}
  

数据冲突检测器当前支持的系统

• linux/amd64
• linux/ppc64le
• linux/arm64
• freebsd/amd64
• netbsd/amd64
• darwin/amd64
• windows/amd64

运行时开销

开启冲突检测,通常程序的内存使用会增加5~10倍,执行耗时增加2~20倍.

注意事项: 数据冲突检测器为每个defer和recover语句分配额外8字节,该内存直到协程退出才会释放,这意味着如果你有一个长时间运行的协程goroutine,它会周期性的调用defer和recover,导致程序内存使用持续增长,且这些内存分配不会显示在runtime.ReadMemStats(运行时读内存统计)和runtime/pprof(运行时性能调试工具pprof统计)中.

参考文档:

Go语言高级编程 (Advanced Go Programming)