1. 简介(Introduction)
本文翻译了原文并加入了自己的理解。
主要介绍多个 Go协程之间对同一个变量并发读写时需要注意的同步措施和执行顺序问题。并列出几个常见错误。
Go 内存模型涉及到多个 Go协程之间对同一个变量的读写。
假如有一个变量,其中一个 Go协程(a) 写这个变量,另一个 Go协程(b) 读这个变量;Go 内存模型定义了什么情况下 Go协程(b) 能够确保读取到由 Go协程(a) 写入的值。
2. 建议(Advice)
channelsyncsync/atomic
3. 发生在…之前(Happens Before)
除了重排序需要理解,其余概念其实没那么重要,看后面的例子就懂了。
3.1 重排序
当只有一个 Go协程时,对同一个变量的读写必然是按照代码编写的顺序来执行的。对于多个变量的读写,如果重新排序不影响代码逻辑的正常执行,编译器和处理器可能会对多个变量的读写过程重新排序。
a = 1; b = 2
但是,因为重新排列执行顺序的情况的存在,会导致**某个 Go协程所观察到的执行顺序可能与另一个 Go协程观察到的执行顺序不一样。**可能另一个 Go协程 观察到的事实是 b 的值先被更新,而 a 的值被后更新。
3.2 happens-before
为了表征读写需求,我们可以定义 happens-before,用来表示 Go 语言中某一小段内存命令的执行顺序。
- 如果事件 e1 发生在事件 e2 之前,此时我们就认为 e2 发生在 e1 之后。
- 如果事件 e1 既不发生在事件 e2 之前,也不发生在 e2 之后,此时我们就认为 e1 和 e2 同时发生(并发)(并发 ≠ 并行)。
3.3 规则
在只有一个 Go协程的内部,happens-before的顺序就是代码显式定义的顺序。当 Go协程 不仅仅局限在一个的时候,存在下面两个规则:
vrw
rww’ww’r
rwwrrw
wrvwr
规则二的条件比规则一的条件更为严格,它要求没有其他的写操作和 w、r 并发地发生。
在一个 Go协程 里是不存在并发的,因此规则一和规则二是等效的:读操作 r 可以观察到最近一次写操作 w 写入的值。
但是,当多个协程访问一个共享变量时,就必须使用同步事件来构建 happens-before 的条件,从而保证读操作观察到的一定是想要的写操作。
v
如果变量的值大于单机器字(CPU 从内存单次读取的字节数),那么 CPU 在读和写这个变量的时候是以一种不可预知顺序的多次执行单机器字的操作,这也是 sync/atomic 包存在的价值。
4. 同步(Synchronization)
4.1 初始化(Initialization)
程序的初始化是在一个单独的 Go协程 中进行的,但是这个协程可以创建其他的 Go协程 并且二者并发执行。
initinit
pqqinitpinitmain.maininit
4.2 Go协程的创建(Goroutine creation)
go
hello
4.3 Go协程的销毁(Goroutine destruction)
Go协程的退出无法确保发生在程序的某个事件之前。比如下面的例子:
hello
一些激进的编译器可能会在编译阶段删除上面代码中的整个 go 语句。
如果某个 Go协程 里发生的事件必须要被另一个 Go协程 观察到,需要使用同步机制进行保证,比如使用锁或者信道(channel)通信来构建一个相对的事件发生顺序。
4.4 信道通信(Channel communication)
这部分介绍通过 channel 实现并发顺序控制。
有缓存channel
信道通信是多个 Go协程 间事件同步的主要方式。在某个特定的信道上发送一个数据,则对应地可以在这个信道上接收一个数据,一般情况下是在不同的 Go协程 间发送与接收。
- 规则一:在某个信道上发送数据的事件发生在相应的接收事件之前。
即一定是先发送数据,才能接收到数据这个顺序。
上面这段代码保证了 `hello, world` 的打印。因为信道的写入事件 `c <- 0` 发生在读取事件 `<-c` 之前,而 `<-c` 发生在 `print(a)`之前。信道未被读取时协程会阻塞。
close(c)c <- 0
无缓存 channel
- 规则三:对于没有缓存的信道,数据的接收事件发生在数据发送完成之前。
即信道容量为0时,只有发送的信息被读取了才算发送成功,否则阻塞。
比如下面的代码(类似上面给出的代码,但是使用了没有缓存的信道,且发送和接收的语句交换了一下):
上面这段代码依然可以保证可以打印 `hello, world`。因为信道的写入事件 `c <- 0` 发生在读取事件 `<-c` 之前,而 `<-c` 发生在写入事件 `c <- 0` 完成之前,同时写入事件 `c <- 0` 的完成发生在 `print` 之前。
上面的代码,如果信道是带缓存的(比如 `c = make(chan int, 1)`),程序将不能保证会打印出 `hello, world`,它可能会打印出空字符串,也可能崩溃退出,或者表现出一些其他的症状。
规则抽象
- 规则四:对于容量为 C 的信道,接收第 k 个元素的事件发生在第 k+C 个元素的发送之前。
规则四是规则三在带缓存的信道上的推广。 - 它使得带缓存的信道可以模拟出计数信号量:**信道中元素的个数表示活跃数,信道的容量表示最大的可并发数;发送一个元素意味着获取一个信号量,接收一个元素意味着释放这个信号量。**这是一种常见的限制并发的用法。
- 下面的代码给工作列表中的每个入口都开启一个 Go协程,但是通过配合一个固定长度的信道保证了同时最多有 3 个运行的工作(最多 3 个并发)。
4. 锁
syncsync.Mutexsync.RWMutex
sync.Mutexsync.RWMutexln < ml.Unlock()l.Lock()
即先解开上一次锁才能上这一次锁。
比如下面的代码:
上面这段代码保证能够打印 `hello, world`。`l.Unlock()`的第 1 次调用返回(在函数 f 内部)发生在 `l.Lock()` 的第 2 次调用返回之前,后者发生在 `print` 之前。
sync.RWMutexll.RLockl.Unlockl.RUnlockl.Lock
5. 单次运行
syncOnce
once.Do(f)ff()f()f
f()once.Do(f)once.Do(f)
比如下面的代码:
wg sync.WaitGroupsetup oversetupsetupprinthello, worldsetup
6. 不正确的同步方式
6.1 案例一
对某个变量的读操作 r 一定概率可以观察到对同一个变量的并发写操作 w,但是即使这件事情发生了,也并不意味着发生在 r 之后的其他读操作可以观察到发生在 w 之前的其他写操作。(这里的先后指的是代码里面声明的操作的先后顺序,而不是实际执行时候的)
比如下面的代码:
g
上面的事实可以证明下面的几个常见的错误。
6.2 案例二
双重检查锁定尝试避免同步带来的开销。比如下面的例子,twoprint 函数可能会被错误地编写为:
doprintdonea
6.3 案例三
另一个常见的错误用法是对某个值的循环检查,比如下面的代码:
maindonea
maindonemainfor
上面这个错误有一种变体,如下面的代码所示:
maing != nilforg.msg
避免上面几个错误用法的方式是一样的:显式使用同步语句。
7. 总结
通过上面所有的例子,不难看出解决多goroutine下共享数据可见性问题的方法是在访问共享数据时候施加一定的同步措施。