Golang 并发编程核心篇 —— 内存可见性

• 背景

• 什么是内存可见性 ?

• 多级缓存设计

• 编译优化和 cpu 乱序执行

• 什么是 happens-before ?

• 为什么要有 happens-before 规则？

• C 语言的内存可见性

• `volatile` 关键字

• memory barrier

• Golang 的 happens-before

• Initialization

• Goroutine creation

• Goroutine destruction

• Channel communiaction

• Locks

• Once

• 错误的例子

• 总结

背景

Go 语言最大的特殊就是高并发能力，以 Goroutine 协程为执行体充分利用现代处理器的计算能力，但是并发机制也带来了协程并发安全的问题。现代处理器都是多级缓存的结构，并且编译器会对指令进行重排序和优化，cpu 执行也可能乱序执行，那么如何保证一个协程执行体写操作被另一个执行体正确可见？Go 的内存模型（ Go Memory Model ）定义了一套 happens-before 准则，只有依赖于这个准则的程序，才能保证并发逻辑正确执行。

什么是内存可见性 ?

Golang 的内存可见性，估计很多 Golang 程序员自己都没注意过？其实在很多语言里面是有这方面的直接体现的，Golang 自然也有，那么什么是内存可见性？通俗来讲就是操作结果对别人可见。通常我们也只在并发环境才会讨论这个问题，单执行体环境这个前面执行的指令对后面的指令都是可见的。

举个例子：

如上代码，经过编译器和编译优化和 cpu 的乱序执行，执行顺序可能并不是 （A，B，C） 这样执行，也可能是 （B，A，C），甚至（C，A，B），只要保证了程序的正确性，保证了我们上层代码的语义，我们允许编译器和 cpu 施展各自的手段去优化。就可见性来说，A 的结果对于 B 是可见的，B的结果对于 C 是可见的。

多级缓存设计

现代的处理器架构都是多级缓存的，cpu 有 L1，L2，L3 缓存，最后才是 DRAM，对于编译器生成的代码也是优先使用寄存器，其次才是主存。所以在并发场景下，必然是存在一致性问题的，一个执行体对变量的修改可能并不能立马对其他执行体可见。

编译优化和 cpu 乱序执行

编译器会对代码进行优化，包括代码的调整，重排等操作。cpu 执行指令也是以乱序执行指令的，这些都是为了性能的考虑。

什么是 happens-before ?

happens-before 是比 指令重排、内存屏障这些概念更上层的东西，是语言层面给我们的承诺。我们没有办法穷举在所有计算机架构下重排序会如何发生，也没办法为重排序定义该在什么时候插入屏障来阻止重排序、刷新 cache 的顺序，这个是无法做到的事情。

如何理解 Happens-Before 呢？如果直接翻译成“先行发生”，那就走远了，happens-before 并不是从物理时间上说前面一个操作发生在后续操作的前面，它真正要表达的是：前面一个操作的结果对后续操作是可见的（可以理解成逻辑上的操作顺序是有先后的）。happens-before 本质是一种偏序关系，所以要满足传递性。我们说 A happens-before B ，也就是说 A 的结果对于 B 是可见的，简称 A <= B，或者 hb(A, B)。

为什么要有 happens-before 规则？

• 首先，如果 Go 语言提供屏障操作让 Go 开发者自己决定何时插入屏障，那么并发代码是难写且容易出错的（技术上是可行的，主要是太偏底层，比如 c 就是这样搞）；

• 再者，对于编译器和 cpu 来说，这些内存屏障，优化屏障都是约束，让底层无法随心所欲的进行优化，所以这些约束肯定是越少越好；

程序员希望不要底层搞那些花里胡哨的，最好别搞优化，对底层的约束越多越好，最好底层的指令就和我写的代码一模一样就好，但是编译器和 cpu 处理器却总喜欢搞些花的，希望上层对自己的约束越少越好。怎么平衡这个矛盾？

Go 的选择是为程序员提供了有限几条类似公理的规则，这个就是我们的 happens-before 规则（类似其他高级语言，也是类似的，比如 java ）。Go 程序员开发的时候，只有遵守了这些规则，才能保证正确的语义，满足正确的可见性。这些规则以外的事情，不属于 Go 的承诺，自然结果也是未知。

编译器和 cpu 指令只需要保证这几条 happens-before 的规则语义不变，在此基础上做任何优化都是允许的。换句话说，happens-before 约束了编译器的优化行为，允许编译器优化，但是要求编译器优化后一定遵守 happens-before 规则。

C 语言的内存可见性

内存可见性是一个通用性质的问题，类似于 c/c++，golang，java 都存在相应的策略。作为比较，我们先思考下 c 语言，在 c 里面却几乎没有 happens-before 的理论规则，究其原因还是由于 c 太底层了，常见 c 的内存可见性一般用两个比较原始的手段来保证：

volatile

 关键字

volatilevolatile

vo 我们先以一个简单的常见的 c 代码举例：

这段代码，编译器根据自己的优化理解，会在编译期间直接展开翻译成（或者每次都直接取寄存器里的值，寄存器里永远存的是 0 ）：

donedonevolatiledone

memory barrier

内存屏障（memory barrier），又叫做内存栅栏（memory fence），分为两类：

1. 编译器屏障（又叫做优化屏障）—— 针对编译期间的代码生成

2. cpu 内存屏障 —— 针对运行期间的指令运行

这两类屏障都可以在 c 里面可以手动插入，比如以下：

pthread_mutx_t

小结：c 语言保证内存可见性的的方式非常简单和原始，几乎是在指令级别的操作考虑。

Golang 的 happens-before

happens-before 我们已经知道是什么东西了，本质上就是一个逻辑顺序的保证。happens-before 是比指令重排、内存屏障更上层的概念，由编程语言层面做的承诺。Golang 有少许几个承诺的 happens-before 规则，我们应用程序只有合理应用且遵守这些规则，才能保证并发的时候，内存可见性如我们预期。

划重点：这些 happens-before 是 Golang 给出的承诺保证，程序员只有遵守这些准则，就能保证内存可见性的正确。

A happen-before B

Golang 在 5 个方面提供了 happens-before  的规则承诺。

注意，后面我们说 A happens-before B，等价于 A <= B，等价于 A 先于 B，等价于 A 结果可见于 B，“先于”说的是可见性，并不是严格的物理时间顺序，注意下区别，后面不再解释。

我们展开看下 Golang 具体是提供了那几条 happens-before 规则，按照场景和类型分类，具体的规则如下：

Initialization

官方描述：

If a package p imports package q, the completion of q's init functions happens before the start of any of p's.

规则解释：

import packageimport q

举个例子：

initimport "x"

Goroutine creation

官方描述：

The go statement that starts a new goroutine happens before the goroutine's execution begins.

规则解释：

该规则说的是 goroutine 创建的场景，创建函数本身先于 goroutine 内的第一行代码执行。

举个例子：

按照这条 happens-before 规则：

1. （2）的结果可见于（3），也就是 2 <= 3；

2. （1）天然先于（2），有 1 <= 2

println(a)a=1println

Goroutine destruction

官方描述：

The exit of a goroutine is not guaranteed to happen before any event in the program.

规则解释：

该规则说的是 goroutine 销毁的场景，这条规则说的是，goroutine 的 exit 事件并不保证先于所有的程序内的其他事件，或者说某个 goroutine exit 的结果并不保证对其他人可见。

举个例子：

换句话说，协程的销毁流程本身没有做任何 happens-before 承诺。上面的实例里面的 goroutine 的退出结果不可见于下面的任何一行代码。

Channel communiaction

官方描述：

1. A send on a channel happens before the corresponding receive from that channel completes.

2. The closing of a channel happens before a receive that returns a zero value because the channel is closed.

3. A receive from an unbuffered channel happens before the send on that channel completes.

4. The kth receive on a channel with capacity C happens before the k+Cth send from that channel completes.

规则解释：

channel 涉及到的 happens-before 规则一共有 4 条，数量最多。从这个条数我们也能看出来，Golang 里面 channel 才是保证内存可见性，有序性，代码同步的一等选择，我们一条条解析下：

规则一解释：

A send on a channel happens before the corresponding receive from that channel completes.

channel 的元素写入（send） 可见于 对应的元素读取（receive）操作完成。注意关键字：“对应的元素，指的是同一个元素”，说的是同一个元素哈。换句话说，一个元素的 send 操作先于这个元素 receive 调用完成（结果返回）。

举个例子：

a="hello, world"print(a)

<-c

print(a)a

规则二解释：

The closing of a channel happens before a receive that returns a zero value because the channel is closed.

channel 的关闭（还未完成）行为可见于 channel receive 返回（ 返回 0， 因为 channel closed 导致 ）；

举个例子：

c<- 0close(c)

print(a)a

规则三解释：

A receive from an unbuffered channel happens before the send on that channel completes.

第三条规则是针对 no buffer 的 channel 的，no buffer 的 channel 的 receive 操作可见于 send 元素操作完成。

举个例子：

c<-0

print(a)a

c<-0c <- 0

var c = make(chan int, 1)print(a)

规则四解释：

The kth receive on a channel with capacity C happens before the k+Cth send from that channel completes.

第四条规则是通用规则，说的是，如果 channel 的 ringbuffer 长度是 C ，那么第 K 个元素的 receive 操作先于 第 K+C 个元素 的 send 操作完成；

仔细思考下这条规则，当 C 等于 0 的时候，其实说的就是规则三，也就说 no buffer 的 channel 只是这条规则的一种特殊情况。

举个例子：

以上面的规则，先举一个简单形象的例子：

B 操作结果可见于 A（或者说，逻辑上 B 先于 A 执行），那么如果时间上，先到了 A 这一行怎么办？就会等待，等待 B 执行完成，B 返回之后，A 才会唤醒且 send 操作完成。只有这样，才保证了本条 happens-before 规则的语义不变，保证 B 先于 A 执行。Golang 在 chan 的实现里保证了这一点。

通俗的来讲，对于这种 buffer channel，一个坑只能蹲一个人，第 K+C 个元素一定要等第 K 个元素腾位置，chan 内部就是一个 ringbuffer，本身就是一个环，所以第 K+C 个元素和第 K 个元素要的是指向同一个位置，必须是 [ The kth receive ] happens-before [ the k+Cth send from that channel completes. ]

那我们再仔细思考下，这就类似一种计数的信号量控制。

• ringbuffer 当前里面的元素相当于当前的资源消耗；

• channel 的 ringbuffer 容量大小相当于最大的资源数；

• send 一个元素相当于 acquire 一个信号量；

• receive 相当于 release 一个信号量（腾出一个坑位）；

• 由于 Golang 承诺的这条 happens-before 规则，指明了第 K 个元素和第 K + C （同坑位）的同步行为；

这个跟我们用来限制并发数的场景是一样的，再看一个官方的例子：

这个不就是一个限制 3 并发的用法嘛。

Locks

官方描述：

1. For any sync.Mutex or sync.RWMutex variable l and n < m, call n of l.Unlock() happens before call m of l.Lock() returns.

2. For any call to l.RLock on a sync.RWMutex variable l, there is an n such that the l.RLock happens (returns) after call n to l.Unlock and the matching l.RUnlock happens before call n+1 to l.Lock.

规则解释：

锁相关的 happens-before 规则有两条。

规则一解释：

For any sync.Mutex or sync.RWMutex variable l and n < m, call n of l.Unlock() happens before call m of l.Lock() returns.

sync.Mutexsync.RWMutexL.Unlock()L.Lock()

举个例子：

这个例子推导：

1. A <= B （单协程上下文指令顺序，天然保证）

2. B <= E （协程创建场景的 happens-before 承诺，见上）

3. E <= F

4. F <= C （这个就是本规则了，承诺了第 1 次的解锁可见于第二次的加锁，golang 为了守住这个承诺，所以必须让 C 行等待着 F 执行完）

5. C <= D

print(a)

这条规则规定的是加锁和解锁的一个逻辑关系，讲的是谁等谁的关系。该例子讲的就是 golang 为了遵守这个承诺，保证 C 等 F。

规则二解释：

For any call to l.RLock on a sync.RWMutex variable l, there is an n such that the l.RLock happens (returns) after call n to l.Unlock and the matching l.RUnlock happens before call n+1 to l.Lock.

sync.RWMutexL.Unlock( )L.Rlock( )L.Runlock( )L.Lock()

我换一个角度说，两个方面：

L.UnlockL.Rlock( )L.RUnlockL.Lock( )

Once

官方描述：

A single call of f() from once.Do(f) happens (returns) before any call of once.Do(f) returns.

规则解释：

f( )once.Do(f)f( )once.Do(f)

举个例子：

setup( )once.Do(setup)print(a)

错误的例子

大家仔细理解下面错误的例子，再思考下 happens-before 代表的含义，happens-before 指的是结果可见于，而非时间顺序。

print(a)

a="hello, world"done=truedone

goroutine: setup 和 goroutine: main 这两者之间的没有存在承诺的规则，无法保证 A <= B 这个可见性。

怎么修正它？

我们再往深走一点，就拿上面的例子来讲，如果我要满足正确的可见性，怎么办？活学活用，想到了 no buffer channel 有一条规则：

A receive from an unbuffered channel happens before the send on that channel completes.

原先 setup 所在的 goroutine 和 main 所在的 goroutine 这两个 goroutines 不存在可见性保证，所以才导致这个问题，我们只需要在合适的位置加上可见性保证，如上例，只需要加上 C 和 D 两个卡点，这条规则是 golang 明确承诺的 happens-before 规则（no buffer channel 的 receive happens-before send 操作完成），推导：

1. C <= D；

2. 由于 A <= C ，D <= B；

print(a)

总结

1. 内存可见性是程序的通用问题，无论哪个语言都会有考虑和处理，区别只在于处理形式；

2. c 处理的比较原始，使用 volatile 关键字禁止编译优化，使用内存屏障禁止编译优化和运行指令优化；

3. happens-before 是更高层面的东西，是编程语言明确保证的因果关系（逻辑结果先后关系），多个高级语言都有此章节，golang，java 等大同小异；

4. happens-before 不是指时间的执行顺序，而是指结果可见性，这一点非常重要；

5. golang 提供了关于 package init，goroutine create，goroutine destroy，channel communication，locks，once 五个方面的 happens-before 规则，其中 channel 和 locks 涉及到的最多，所以 channel，locks 也是最常见保证内存正确可见性的手段；

6. golang 程序员只需要对照语言承诺的 happens-before 规则，实现正确的并发程序就可以保证正确的可见性，而编译器和 cpu 处理器在此有限的 happens-before 规则限制内可以自由发挥，尽情优化逻辑。这样两者得到较好的平衡；

7. 本文的大部分代码实例都来自于官方例子，非常经典和适用理解；

往期推荐

往期推荐

golang 内存管理分析

Golang 数据结构到底是怎么回事？gdb调一调？

Go 最细节篇 — chan 为啥没有判断 close 的接口 ?

golang  chan 最详细原理剖析，全面源码分析！看完不可能不懂的！

欢迎关注Go招聘公众号，获取更多精彩内容。

               

                               Go招聘                                    

Golang 相关求职和招聘，以及面试题、经验分享，Go 语言其他知识和职场也是值得分享的。

290篇原创内容                        

公众号

后台资料分享（后台回复以下数字获取对应资源）
100:Go简历模板 | 101:Go最全面试集锦 | 102:Go超级简历 | 103:Go安全指南 | 1024:LeetCode刷题指南 | 6379:redis集锦 

往期精彩回顾（点击关键词查看文章）

城市内推

北京 | 上海 | 深圳 | 杭州  | 广州 | 成都 | 西安 |  重庆 | 珠海  | 非996 | 外企.远程办公 

大厂招聘

百度 | 阿里 | 腾讯 | 字节跳动 | 360  | 安全企业 | 京东 | 贝壳 | 滴滴 | 搜狗 | 新浪 | 探探 | 好未来 | 金山云 | 伴鱼 | 联通数科  | ApiSix | AiBee | 游戏公司 | 区块链 | 跨境电商 | 电商 

资源分享

Go项目 | Go资源 |  Rust项目 | Python项目 | 前端项目 |

面试专题

面经 | 面试题 | 每日一股 

Golang专题

每周一库 |  Go好文 

来都来了，点个“在看”再走叭~~             

               

本文使用 文章同步助手 同步