由于golang中的go是非常方便的，加上函数又非常容易隐藏go。所以很多时候，当我们写出一个程序的时候，我们并不知道这个程序在并发情况下会不会出现什么问题。所以在本质上说，goroutine的使用增加了函数的并发问题，这个问题，有经验的开发人员还是比较容易发现的，但是，很多时候，并发问题隐藏得非常深，即使是有经验的人，也不太容易发现或者 Debug 出来。针对这个问题，Go 提供了一个检测并发访问共享资源是否有问题的工具： race detector，它可以帮助我们自动发现程序有没有 data race 的问题。
Go race detector 是基于 Google 的 C/C++ sanitizers 技术实现的，编译器通过探测所有的内存访问，加入代码能监视对这些内存地址的访问（读还是写）。在代码运行的时候，race detector 就能监控到对共享变量的非同步访问，出现 race 的时候，就会打印出警告信息。
接下来看看我下面的代码，明显是有并发问题的：
在编译（compile）、测试（test）或者运行（run）Go 代码的时候，加上 race 参数，就有可能发现并发问题。比如在上面的例子中，我们可以加上 race 参数运行，检测一下是不是有并发问题。如果你 go run -race main.go，就会输出警告信息
这个警告不但会告诉你有并发问题，而且还会告诉你哪个 goroutine 在哪一行对哪个变量有写操作，同时，哪个 goroutine 在哪一行对哪个变量有读操作，就是这些并发的读写访问，引起了 data race。
例子中的 goroutine 8 对内存地址 0x00c00012a068 有读的操作（main.go 文件第 16 行），同时，goroutine 7 对内存地址 0x00c00012a068 有写的操作（main.go 文件第 16 行）。而且还可能有多个 goroutine 在同时进行读写，所以，警告信息可能会很长。
虽然这个工具使用起来很方便，但是，因为它的实现方式，只能通过真正对实际地址进行读写访问的时候才能探测，所以它并不能在编译的时候发现 data race 的问题。而且，在运行的时候，只有在触发了 data race 之后，才能检测到，如果碰巧没有触发（比如一个 data race 问题只能在 2 月 14 号零点或者 11 月 11 号零点才出现），是检测不出来的。并且 把开启了 race 的程序部署在线上，还是比较影响性能的， 所以基本是在测试环境使用，不是在正式环境开启。
有疑问加站长微信联系（非本文作者）
