来自公众号：Gopher指北

Go 内存模型明确指出，一个 goroutine 如何才能观察到其他 goroutine 对同一变量的写操作。

当多个 goroutine 并发同时存取同一个数据时必须把并发的存取操作序列化。在 Go 中保证读写的序列化可以通过 channel 通信或者其他同步原语（例如 sync 包中的互斥锁、读写锁和 sync/atomic 中的原子操作）。

Happens Before

在单 goroutine 中，读取和写入的行为一定是和程序指定的执行顺序表现一致。换言之，编译器和处理器在不改变语言规范所定义的行为前提下才可以对单个 goroutine 中的指令进行重排序。

a := 1b := 2

由于指令重排序，b := 2可能先于a := 1执行。单 goroutine 中，该执行顺序的调整并不会影响最终结果。但多个 goroutine 场景下可能就会出现问题。

var a, b int// goroutine Ago func() {    a := 5    b := 1}()// goroutine Bgo func() {    for b == 1 {}    fmt.Println(a)}()

执行上述代码时，预期 goroutine B 能够正常输出 5，但因为指令重排序，b := 1可能先于a := 5执行，最终 goroutine B 可能输出 0。

注：上述例子是个不正确的示例，仅作说明用。

为了明确读写的操作的要求，Go 中引入了happens before，它表示执行内存操作的一种偏序关系。

happens-before 的作用

多个 goroutine 访问共享变量时，它们必须建立同步事件来确保 happens-before 条件，以此确保读能够观察预期的写。

什么是 Happens Before

如果事件 e1 发生在事件 e2 之前，那么我们说 e2 发生在 e1 之后。 同样，如果 e1 不在 e2 之前发生也没有在 e2 之后发生，那么我们说 e1 和 e2 同时发生。

在单个 goroutine 中，happens-before 的顺序就是程序执行的顺序。那 happens-before 到底是什么顺序呢？我们看看下面的条件。

如果对于一个变量 v 的读操作 r 和写操作 w 满足下述两个条件，r 才允许观察到 w：

1. r 没有发生在 w 之前。

2. 没有其他写操作发生在 w 之后和 r 之前。

为了保证变量 v 的一个读操作 r 能够观察到一个特定的写操作 w，需要确保 w 是唯一允许被 r 观察的写操作。那么，如果 r、w 都满足以下条件，r 就能确保观察到 w：

1. w 发生在 r 之前。

2. 其他写操作发生在 w 之前后者 r 之后。

单 goroutine 中不存在并发，这两个条件是等价的。老许在此基础上扩展一下，对于单核心的运行环境这两组条件同样等价。并发情况下，后一组条件比第一组更加严格。

假如你很疑惑，那就对了！老许最开始也很疑惑，这两组条件就是一样的呀。为此老许特地和原文进行了反复对比确保上述的理解是没有问题的。

我们换个思路，进行反向推理。如果这两组条件一样，那原文没必要写两次，果然此事并不简单。

在继续分析之前，要先感谢一下我的语文老师，没有你我就无法发现它们的不同。

r没有发生在w之前，则 r 可能的情况是 r 发生在 w 之后或者和 w 同时发生，如下图（实心表示可同时）。

没有其他写操作发生在w之后和r之前，则其他写 w'可能发生在 w 之前或者和 w 同时发生，也可能发生在 r 之后或者和 r 同时发生，如下图（实心表示可同时）。

第二组条件就很明确了，w 发生在 r 之前且其他写操作只能发生在 w 之前或者 r 之后，如下图（空心表示不可同时）。

到这儿应该明白为什么第二组条件比第一组条件更加严格了吧。在第一组的条件下是允许观察到 w，第二组是保证能观察到 w。

Go 中的同步

下面是 Go 中约定好的一些同步事件，它们能确保程序遵循 happens-before 原则，从而使并发的 goroutine 相对有序。

Go 的初始化

程序初始化运行在单个 goroutine 中，但是该 goroutine 可以创建其他并发运行的 goroutine。

如果包 p 导入了包 q，则 q 包 init 函数执行结束先于 p 包 init 函数的执行。main 函数的执行发生在所有 init 函数执行完成之后。

goroutine 的创建结束

goroutine 的创建先于 goroutine 的执行。老许觉得这基本就是废话，但事情总是没有那么简单，其隐含之意大概是 goroutine 的创建是阻塞的。

func sleep() bool {
	time.Sleep(time.Second)
	return true
}
 
go fmt.Println(sleep())

上述代码会阻塞主 goroutine 一秒，然后才创建子 goroutine。

goroutine 的退出是无法预测的。如果用一个 goroutine 观察另一个 goroutine，请使用锁或者 Channel 来保证相对有序。

Channel 的发送和接收

Channel 通信是 goroutine 之间同步的主要方式。

• Channel 的发送动作先于相应的接受动作完成之前。

• 无缓冲 Channel 的接受先于该 Channel 上的发送完成之前。

这两点总结起来分别是开始发送、开始接受、发送完成和接受完成四个动作，其时序关系如下。

开始发送 > 接受完成开始接受 > 发送完成

注意：开始发送和开始接受并无明确的先后关系

• Channel 的关闭发生在由于通道关闭而返回零值接受之前。

• 容量为 C 的 Channel 第 k 个接受先于该 Channel 上的第 k+C 个发送完成之前。

这里使用极限法应该更加易于理解，如果 C 为 0，k 为 1 则其含义和无缓冲 Channel 的一致。

Lock

对于任何 sync.Mutex 或 sync.RWMutex 变量 l 以及 n < m，第 n 次 l.Unlock()的调用先于第 m 次 l.Lock()的调用返回。

假设 n 为 1，m 为 2，则第二次调用 l.Lock()返回前一定要先调用 l.UnLock()。

对于 sync.RWMutex 的变量 l 存在这样一个 n，使得 l.RLock()的调用返回在第 n 次 l.Unlock()之后发生，而与之匹配的 l.RUnlock()发生在第 n + 1 次 l.Lock()之前。

不得不说，上面这句话简直不是人能理解的。老许将其翻译成人话：

有写锁时：l.RLock()的调用返回发生在 l.Unlock()之后。

有读锁时：l.RUnlock()的调用发生在 l.Lock()之前。

注意：调用 l.RUnlock()前不调用 l.RLock()和调用 l.Unlock()前不调用 l.Lock()会引起 panic。

Once

once.Do(f)中 f 的返回先于任意其他 once.Do 的返回。

不正确的同步

错误示范一

var a, b int
func f() {	a = 1	b = 2}
func g() {	print(b)	print(a)}
func main() {	go f()	g()}

这个例子看起来挺简单，但是老许相信大部分人应该会忽略指令重排序引起的异常输出。假如 goroutine f 指令重排序后，b=2先于a=1发生，此时主 goroutine 观察到 b 发生变化而未观察到 a 变化，因此有可能输出20。

老许在本地实验了多次结果都是输出00，20这个输出估计只活在理论之中了。

错误示范二

var a stringvar done bool
func setup() {	a = "hello, world"	done = true}
func doprint() {	if !done {		once.Do(setup)	}	print(a)}
func twoprint() {	go doprint()	go doprint()}

这种双重检测本意是为了避免同步的开销，但是依旧有可能打印出空字符串而不是“hello, world”。说实话老许自己都不敢保证以前没有写过这样的代码。现在唯一能想到的场景就是其中一个 goroutine doprint 执行到done = true（指令重排序导致done=true先于a="hello, world"执行）时，另一个 goroutine doprint 刚开始执行并观察到 done 的值为 true 从而打印空字符串。

最后，衷心希望本文能够对各位读者有一定的帮助。当然，发现错误也还请及时联系老许改正。

参考

https://golang.org/ref/mem