# 15 | 内存模型：Go如何保证并发读写的顺序？ 你好，我是鸟窝。 Go官方文档里专门介绍了Go的[内存模型](https://golang.org/ref/mem)，你不要误解这里的内存模型的含义，它并不是指Go对象的内存分配、内存回收和内存整理的规范，它描述的是并发环境中多goroutine读相同变量的时候，变量的可见性条件。具体点说，就是指，在什么条件下，goroutine在读取一个变量的值的时候，能够看到其它goroutine对这个变量进行的写的结果。 由于CPU指令重排和多级Cache的存在，保证多核访问同一个变量这件事儿变得非常复杂。毕竟，不同CPU架构（x86/amd64、ARM、Power等）的处理方式也不一样，再加上编译器的优化也可能对指令进行重排，所以编程语言需要一个规范，来明确多线程同时访问同一个变量的可见性和顺序（ Russ Cox在麻省理工学院 [6.824 分布式系统Distributed Systems课程](https://pdos.csail.mit.edu/6.824/) 的一课，专门介绍了相关的[知识](http://nil.csail.mit.edu/6.824/2016/notes/gomem.pdf)）。在编程语言中，这个规范被叫做内存模型。 除了Go，Java、C++、C、C#、Rust等编程语言也有内存模型。为什么这些编程语言都要定义内存模型呢？在我看来，主要是两个目的。 * 向广大的程序员提供一种保证，以便他们在做设计和开发程序时，面对同一个数据同时被多个goroutine访问的情况，可以做一些串行化访问的控制，比如使用Channel或者sync包和sync/atomic包中的并发原语。 * 允许编译器和硬件对程序做一些优化。这一点其实主要是为编译器开发者提供的保证，这样可以方便他们对Go的编译器做优化。 既然内存模型这么重要，今天，我们就来花一节课的时间学习一下。 首先，我们要先弄明白重排和可见性的问题，因为它们影响着程序实际执行的顺序关系。 # 重排和可见性的问题 **由于指令重排，代码并不一定会按照你写的顺序执行**。 举个例子，当两个goroutine同时对一个数据进行读写时，假设goroutine g1对这个变量进行写操作w，goroutine g2同时对这个变量进行读操作r，那么，如果g2在执行读操作r的时候，已经看到了g1写操作w的结果，那么，也不意味着g2能看到在w之前的其它的写操作。这是一个反直观的结果，不过的确可能会存在。 接下来，我再举几个具体的例子，带你来感受一下，重排以及多核CPU并发执行导致程序的运行和代码的书写顺序不一样的情况。 先看第一个例子，代码如下： ``` var a, b int func f() { a = 1 // w之前的写操作 b = 2 // 写操作w } func g() { print(b) // 读操作r print(a) // ??? } func main() { go f() //g1 g() //g2 } ``` 可以看到，第9行是要打印b的值。需要注意的是，即使这里打印出的值是2，但是依然可能在打印a的值时，打印出初始值0，而不是1。这是因为，程序运行的时候，不能保证g2看到的a和b的赋值有先后关系。 再来看一个类似的例子。 ``` var a string var done bool func setup() { a = "hello, world" done = true } func main() { go setup() for !done { } print(a) } ``` 在这段代码中，主goroutine main即使观察到done变成true了，最后读取到的a的值仍然可能为空。 更糟糕的情况是，main根本就观察不到另一个goroutine对done的写操作，这就会导致main程序一直被hang住。甚至可能还会出现**半初始化**的情况，比如： ``` type T struct { msg string } var g *T func setup() { t := new(T) t.msg = "hello, world" g = t } func main() { go setup() for g == nil { } print(g.msg) } ``` 即使main goroutine观察到g不为nil，也可能打印出空的msg（第17行）。 看到这里，你可能要说了，我都运行这个程序几百万次了，怎么也没有观察到这种现象？我可以这么告诉你，能不能观察到和提供保证（guarantee）是两码事儿。由于CPU架构和Go编译器的不同，即使你运行程序时没有遇到这些现象，也不代表Go可以100%保证不会出现这些问题。 刚刚说了，程序在运行的时候，两个操作的顺序可能不会得到保证，那该怎么办呢？接下来，我要带你了解一下Go内存模型中很重要的一个概念：happens-before，这是用来描述两个时间的顺序关系的。如果某些操作能提供happens-before关系，那么，我们就可以100%保证它们之间的顺序。 # happens-before 在一个goroutine内部，程序的执行顺序和它们的代码指定的顺序是一样的，即使编译器或者CPU重排了读写顺序，从行为上来看，也和代码指定的顺序一样。 这是一个非常重要的保证，我们一定要记住。 我们来看一个例子。在下面的代码中，即使编译器或者CPU对a、b、c的初始化进行了重排，但是打印结果依然能保证是1、2、3，而不会出现1、0、0或1、0、1等情况。 ``` func foo() { var a = 1 var b = 2 var c = 3 println(a) println(b) println(c) } ``` 但是，对于另一个goroutine来说，重排却会产生非常大的影响。**因为Go只保证goroutine内部重排对读写的顺序没有影响**，比如刚刚我们在讲“可见性”问题时提到的三个例子，那该怎么办呢？这就要用到happens-before关系了。 如果两个action（read 或者 write）有明确的happens-before关系，你就可以确定它们之间的执行顺序（或者是行为表现上的顺序）。 Go内存模型通过happens-before定义两个事件（读、写action）的顺序：如果事件e1 happens before 事件e2，那么，我们就可以说事件e2在事件e1之后发生（happens after）。如果e1 不是happens before e2， 同时也不happens after e2，那么，我们就可以说事件e1和e2是同时发生的。 如果要保证对“变量**v**的读操作**r**”能够观察到一个对“变量**v**的写操作**w**”，并且**r**只能观察到**w**对变量**v**的写，没有其它对v的写操作，也就是说，我们要保证**r**绝对能观察到**w**操作的结果，那么就需要同时满足两个条件： 1. w happens before r； 2. 其它对v的写操作（w2、w3、w4, ......） 要么happens before w，要么happens after r，绝对不会和w、r同时发生，或者是在它们之间发生。 你可能会说，这是很显然的事情啊，但我要和你说的是，这是一个非常严格、严谨的数学定义。 对于单个的goroutine来说，它有一个特殊的happens-before关系，Go内存模型中是这么讲的： > Within a single goroutine, the happens-before order is the order expressed by the program. 我来解释下这句话。它的意思是，在单个的goroutine内部， happens-before的关系和代码编写的顺序是一致的。 其实，在这一章的开头我已经用橙色把这句话标注出来了。我再具体解释下。 在goroutine内部对一个局部变量v的读，一定能观察到最近一次对这个局部变量v的写。如果要保证多个goroutine之间对一个共享变量的读写顺序，在Go语言中，可以使用并发原语为读写操作建立happens-before关系，这样就可以保证顺序了。 说到这儿，我想先给你补充三个Go语言中和内存模型有关的小知识，掌握了这些，你就能更好地理解下面的内容。 1. 在Go语言中，对变量进行零值的初始化就是一个写操作。 2. 如果对超过机器word（64bit、32bit或者其它）大小的值进行读写，那么，就可以看作是对拆成word大小的几个读写无序进行。 3. Go并不提供直接的CPU屏障（CPU fence）来提示编译器或者CPU保证顺序性，而是使用不同架构的内存屏障指令来实现统一的并发原语。 接下来，我就带你学习下Go语言中提供的happens-before关系保证。 # Go语言中保证的happens-before关系 除了单个goroutine内部提供的happens-before保证，Go语言中还提供了一些其它的happens-before关系的保证，下面我来一个一个介绍下。 ## init函数 应用程序的初始化是在单一的goroutine执行的。如果包p导入了包q，那么，q的init函数的执行一定 happens before p的任何初始化代码。 这里有一个特殊情况需要你记住：**main函数一定在导入的包的init函数之后执行**。 包级别的变量在同一个文件中是按照声明顺序逐个初始化的，除非初始化它的时候依赖其它的变量。同一个包下的多个文件，会按照文件名的排列顺序进行初始化。这个顺序被定义在[Go语言规范](https://golang.org/ref/spec#Program_initialization_and_execution)中，而不是Go的内存模型规范中。你可以看看下面的例子中各个变量的值： ``` var ( a = c + b // == 9 b = f() // == 4 c = f() // == 5 d = 3 // == 5 全部初始化完成后 ) func f() int { d++ return d } ``` 具体怎么对这些变量进行初始化呢？Go采用的是依赖分析技术。不过，依赖分析技术保证的顺序只是针对同一包下的变量，而且，只有引用关系是本包变量、函数和非接口的方法，才能保证它们的顺序性。 同一个包下可以有多个init函数，甚至一个文件中也可以包含多个相同签名的init函数。 刚刚讲的这些都是不同包的init函数执行顺序，下面我举一个具体的例子，把这些内容串起来，你一看就明白了。 这个例子是一个**main**程序，它依赖包p1，包p1依赖包p2，包p2依赖p3。 ![](https://static001.geekbang.org/resource/image/d5/2a/d5059fab1977602934339e18f9eddb2a.jpg) 为了追踪初始化过程，并输出有意义的日志，我定义了一个辅助方法，打印出日志并返回一个用来初始化的整数值： ``` func Trace(t string, v int) int { fmt.Println(t, ":", v) return v } ``` 包**p3**包含两个文件，分别定义了一个init函数。第一个文件中定义了两个变量，这两个变量的值还会在init函数中进行修改。 我们来分别看下包p3的这两个文件： ``` // lib1.go in p3 var V1_p3 = trace.Trace("init v1_p3", 3) var V2_p3 = trace.Trace("init v2_p3", 3) func init() { fmt.Println("init func in p3") V1_p3 = 300 V2_p3 = 300 } ``` ``` // lib2.go in p3 func init() { fmt.Println("another init func in p3") } ``` 下面再来看看包p2。包p2定义了变量和init函数。第一个变量初始化为2，并在init函数中更改为200。第二个变量是复制的p3.V2\_p3。 ``` var V1_p2 = trace.Trace("init v1_p2", 2) var V2_p2 = trace.Trace("init v2_p2", p3.V2_p3) func init() { fmt.Println("init func in p2") V1_p2 = 200 } ``` 包**p1**定义了变量和init函数。它的两个变量的值是复制的p2对应的两个变量值。 ``` var V1_p1 = trace.Trace("init v1_p1", p2.V1_p2) var V2_p1 = trace.Trace("init v2_p1", p2.V2_p2) func init() { fmt.Println("init func in p1") } ``` **main**定义了init函数和main函数。 ``` func init() { fmt.Println("init func in main") } func main() { fmt.Println("V1_p1:", p1.V1_p1) fmt.Println("V2_p1:", p1.V2_p1) } ``` 运行main函数会依次输出p3、p2、p1、main的初始化变量时的日志（变量初始化时的日志和init函数调用时的日志）： ``` // 包p3的变量初始化 init v1_p3 : 3 init v2_p3 : 3 // p3的init函数 init func in p3 // p3的另一个init函数 another init func in p3 // 包p2的变量初始化 init v1_p2 : 2 init v2_p2 : 300 // 包p2的init函数 init func in p2 // 包p1的变量初始化 init v1_p1 : 200 init v2_p1 : 300 // 包p1的init函数 init func in p1 // 包main的init函数 init func in main // main函数 V1_p1: 200 V2_p1: 300 ``` 下面，我们再来看看goroutine对happens-before关系的保证情况。 ## goroutine 首先，我们需要明确一个规则：**启动goroutine的go语句的执行，一定happens before此goroutine内的代码执行。** 根据这个规则，我们就可以知道，如果go语句传入的参数是一个函数执行的结果，那么，这个函数一定先于goroutine内部的代码被执行。 我们来看一个例子。在下面的代码中，第8行a的赋值和第9行的go语句是在同一个goroutine中执行的，所以，在主goroutine看来，第8行肯定happens before 第9行，又由于刚才的保证，第9行子goroutine的启动happens before 第4行的变量输出，那么，我们就可以推断出，第8行happens before 第4行。也就是说，在第4行打印a的值的时候，肯定会打印出“hello world”。 ``` var a string func f() { print(a) } func hello() { a = "hello, world" go f() } ``` 刚刚说的是启动goroutine的情况，goroutine退出的时候，是没有任何happens-before保证的。所以，如果你想观察某个goroutine的执行效果，你需要使用同步机制建立happens-before关系，比如Mutex或者Channel。接下来，我会讲Channel的happens-before的关系保证。 ## Channel Channel是goroutine同步交流的主要方法。往一个Channel中发送一条数据，通常对应着另一个goroutine从这个Channel中接收一条数据。 通用的Channel happens-before关系保证有4条规则，我分别来介绍下。 **第1条规则是**，往Channel中的发送操作，happens before 从该Channel接收相应数据的动作完成之前，即第n个send一定happens before第n个receive的完成。 ``` var ch = make(chan struct{}, 10) // buffered或者unbuffered var s string func f() { s = "hello, world" ch <- struct{}{} } func main() { go f() <-ch print(s) } ``` 在这个例子中，s的初始化（第5行）happens before 往ch中发送数据， 往ch发送数据 happens before从ch中读取出一条数据（第11行），第12行打印s的值 happens after第11行，所以，打印的结果肯定是初始化后的s的值“hello world”。 **第2条规则是**，close一个Channel的调用，肯定happens before 从关闭的Channel中读取出一个零值。 还是拿刚刚的这个例子来说，如果你把第6行替换成 close(ch)，也能保证同样的执行顺序。因为第11行从关闭的ch中读取出零值后，第6行肯定被调用了。 **第3条规则是**，对于unbuffered的Channel，也就是容量是0的Channel，从此Channel中读取数据的调用一定happens before 往此Channel发送数据的调用完成。 所以，在上面的这个例子中呢，如果想保持同样的执行顺序，也可以写成这样： ``` var ch = make(chan int) var s string func f() { s = "hello, world" <-ch } func main() { go f() ch <- struct{}{} print(s) } ``` 如果第11行发送语句执行成功（完毕），那么根据这个规则，第6行（接收）的调用肯定发生了（执行完成不完成不重要，重要的是这一句“肯定执行了”），那么s也肯定初始化了，所以一定会打印出“hello world”。 这一条比较晦涩，但是，因为Channel是unbuffered的Channel，所以这个规则也成立。 **第4条规则是**，如果Channel的容量是m（m>0），那么，第n个receive一定happens before 第 n+m 个 send的完成。 前一条规则是针对unbuffered channel的，这里给出了更广泛的针对buffered channel的保证。利用这个规则，我们可以实现信号量（Semaphore）的并发原语。Channel的容量相当于可用的资源，发送一条数据相当于请求信号量，接收一条数据相当于释放信号。关于信号量这个并发原语，我会在下一讲专门给你介绍一下，这里你只需要知道它可以控制多个资源的并发访问，就可以了。 ## Mutex/RWMutex 对于互斥锁Mutex m或者读写锁RWMutex m，有3条happens-before关系的保证。 1. 第n次的m.Unlock一定happens before第n+1 m.Lock方法的返回； 2. 对于读写锁RWMutex m，如果它的第n个m.Lock方法的调用已返回，那么它的第n个m.Unlock的方法调用一定happens before 任何一个m.RLock方法调用的返回，只要这些m.RLock方法调用 happens after 第n次m.Lock的调用的返回。这就可以保证，只有释放了持有的写锁，那些等待的读请求才能请求到读锁。 3. 对于读写锁RWMutex m，如果它的第n个m.RLock方法的调用已返回，那么它的第k （k<=n）个成功的m.RUnlock方法的返回一定happens before 任意的m.RUnlockLock方法调用，只要这些m.Lock方法调用happens after第n次m.RLock。 读写锁的保证有点绕，我再带你看看官方的描述： > 对于读写锁l的 l.RLock方法调用，如果存在一个**n**，这次的l.RLock调用 happens after 第n次的l.Unlock，那么，和这个RLock相对应的l.RUnlock一定happens before 第n+1次l.Lock。意思是，读写锁的Lock必须等待既有的读锁释放后才能获取到。 我再举个例子。在下面的代码中，第6行第一次的Unlock一定happens before第二次的Lock（第12行），所以这也能保证正确地打印出“hello world”。 ``` var mu sync.Mutex var s string func foo() { s = "hello, world" mu.Unlock() } func main() { mu.Lock() go foo() mu.Lock() print(s) ``` ## WaitGroup 接下来是WaitGroup的保证。 对于一个WaitGroup实例wg，在某个时刻t0时，它的计数值已经不是零了，假如t0时刻之后调用了一系列的wg.Add(n)或者wg.Done()，并且只有最后一次调用wg的计数值变为了0，那么，可以保证这些wg.Add或者wg.Done()一定 happens before t0时刻之后调用的wg.Wait方法的返回。 这个保证的通俗说法，就是**Wait方法等到计数值归零之后才返回**。 ## Once 我们在[第8讲](https://time.geekbang.org/column/article/301113)学过Once了，相信你已经很熟悉它的功能了。它提供的保证是：**对于once.Do(f)调用，f函数的那个单次调用一定happens before 任何once.Do(f)调用的返回**。换句话说，就是函数f一定会在Do方法返回之前执行。 还是以hello world的例子为例，这次我们使用Once并发原语实现，可以看下下面的代码： ``` var s string var once sync.Once func foo() { s = "hello, world" } func twoprint() { once.Do(foo) print(s) } ``` 第5行的执行一定happens before第9行的返回，所以执行到第10行的时候，sd已经初始化了，所以会正确地打印“hello world”。 最后，我再来说说atomic的保证。 ## atomic 其实，Go内存模型的官方文档并没有明确给出atomic的保证，有一个相关的issue [go# 5045](https://github.com/golang/go/issues/5045)记录了相关的讨论。光看issue号，就知道这个讨论由来已久了。Russ Cox想让atomic有一个弱保证，这样可以为以后留下充足的可扩展空间，所以，Go内存模型规范上并没有严格的定义。 对于Go 1.15的官方实现来说，可以保证使用atomic的Load/Store的变量之间的顺序性。 在下面的例子中，打印出的a的结果总是1，但是官方并没有做任何文档上的说明和保证。 依照Ian Lance Taylor的说法，Go核心开发组的成员几乎没有关注这个方向上的研究，因为这个问题太复杂，有很多问题需要去研究，所以，现阶段还是不要使用atomic来保证顺序性。 ``` func main() { var a, b int32 = 0, 0 go func() { atomic.StoreInt32(&a, 1) atomic.StoreInt32(&b, 1) }() for atomic.LoadInt32(&b) == 0{ runtime.Gosched() } fmt.Println(atomic.LoadInt32(&a)) } ``` # 总结 Go的内存模型规范中，一开始有这么一段话： > If you must read the rest of this document to understand the behavior of your program, you are being too clever. > Don't be clever. 我来说说我对这句话的理解：你通过学习这节课来理解你的程序的行为是聪明的，但是，不要自作聪明。 谨慎地使用这些保证，能够让你的程序按照设想的happens-before关系执行，但是不要以为完全理解这些概念和保证，就可以随意地制造所谓的各种技巧，否则就很容易掉进“坑”里，而且会给代码埋下了很多的“定时炸弹”。 比如，Go里面已经有值得信赖的互斥锁了，如果没有额外的需求，就不要使用Channel创造出自己的互斥锁。 当然，我也不希望你畏手畏脚地把思想局限住，我还是建议你去做一些有意义的尝试，比如使用Channel实现信号量等扩展并发原语。 ![](https://static001.geekbang.org/resource/image/dc/4d/dc68fc5f93a4af96c8f4d45d6282104d.jpg) # 思考题 我们知道，Channel可以实现互斥锁，那么，我想请你思考一下，它是如何利用happens-before关系保证锁的请求和释放的呢？ 欢迎在留言区写下你的思考和答案，我们一起交流讨论。如果你觉得有所收获，也欢迎你把今天的内容分享给你的朋友或同事。