理解go中happens-before规定，寻找并发程序不确定性中的确定性。

引言

先抛开你所熟知的信号量、锁、同步原语等技术，思考这个问题：如何保障并发读写的准确性？一个没有任何并发编程教训的程序员可能会感觉很简略：这有什么问题呢，同时读写能有什么问题，最多就是读到过期的数据而已。一个现实的世界当然是这样，只惋惜实际上的机器世界往往暗藏了很多不容易被觉察的事件。至多有两个行为会影响这个论断：

编译器往往有指令重排序的优化；例如程序员看到的源代码是a=3; b=4;，而实际上执行的程序可能是b=4; a=3；，这是因为编译器为了优化执行效率可能对指令进行重排序；
高级编程语言所反对的运算往往不是原子化的；例如a += 3实际上蕴含了读变量、加运算和写变量三次原子操作。既然整个过程并不是原子化的，就意味着随时有其它“入侵者”侵入批改数据。更为暗藏的例子：对于变量的读写甚至可能都不是原子化的。不同机器读写变量的过程可能是不同的，有些机器可能是64位数据一次性读写，而有些机器是32位数据一次读写。这就意味着一个64位的数据在后者的读写上实际上是分成两次实现的！试想，如果你试图读取一个64位数据的值，先读取了低32的数据，这时另一个线程切进来批改了整个数据的值，最初你再读取高32的值，将高32和低32的数据拼成残缺的值，很显著会失去一个预期以外的数据。

看起来，整个并发编程的世界里一切都是不确定的，咱们不晓得每次读取的变量到底是不是及时、精确的数据。侥幸的是，很多语言都有一个happens-before的规定，能帮忙咱们在不确定的并发世界里寻找一丝确定性。

happens-before

你能够把happens-before看作一种非凡的比拟运算，就如同>、<一样。对应的，还有happens-after，它们之间的关系也如同>、<一样：

如果a happens-before b，那么b happens-after a

那是否存在既不满足a happens-before b，也不满足b happens-before a的状况呢，就如同既不满足a>b，也不满足b>a（意味着b==a)？当然是必定的，这种状况称为：a和b happen concurrently，也就是同时产生，这就回到咱们之前所熟知的世界里了。

happens-before有什么用呢？它能够用来帮忙咱们厘清两个并发读写之间的关系。对于并发读写问题，咱们最关怀的常常是reader是否能精确察看到writer写入的值。happens-before正是为这个问题设计的，具体来说，要想让某次读取r精确察看到某次写入w，只需满足：

w happens-before r；
对变量的其它写入w1，要么w1 happens-before w，要么r happens-before w1；简略了解就是没有其它写入笼罩这次写入；

只有满足这两个条件，那咱们就能够自信地必定咱们肯定能读取到正确的值。

一个新的问题随之诞生：那如何判断a happens-before b是否成立呢？你能够类比思考数学里如何判断a > b是否成立的过程，咱们的做法很简略：

基于一些简略的公理；例如自然数的天然大小：3>2>1
基于比拟运算符的传递性，也就是如果a>b且b>c，则a>c

判断a happens-before b的过程也是相似的：依据一些简略的明确的happens-before关系，再联合happens-before的传递性，推导出咱们所关怀的w和r之间的happens-before关系。

happens-before传递性：如果a happens-before b，且b happens-before c，则a happens-before c

因而咱们只须要理解这些明确的happens-before关系，就能在并发世界里寻找到贵重的确定性了。

go语言中的happens-before关系

具体的happens-before关系是因语言而异的，这里只介绍go语言相干的规定，感兴趣能够间接浏览官网文档，有更残缺、精确的阐明。

天然执行

首先，最简略也是最直观的happens-before规定：

在同一个goroutine里，书写在前的代码happens-before书写在后的代码。

例如：

a = 3; // (1)b = 4; // (2)

则(1) happens-before (2)。咱们下面提到指令重排序，也就是理论执行的程序与书写的程序可能不统一，但happens-before与指令重排序并不矛盾，即便可能产生指令重排序，咱们仍然能够说（1) happens-before (2)。

初始化

每个go文件都能够有一个init办法，用于执行某些初始化逻辑。当咱们开始执行某个main办法时，go会先在一个goroutine里做初始化工作，也就是执行所有go文件的init办法，这个过程中go可能创立多个goroutine并发地执行，因而通常状况下各个init办法是没有happens-before关系的。对于init办法有两条happens-before规定：

1.a 包导入了 b包，此时b包的init办法happens-before a包的所有代码；
2.所有init办法happens-before main办法；

goroutine

goroutine相干的规定次要是其创立和销毁的：

1.goroutine的创立 happens-before 其执行；
2.goroutine的实现不保障happens-before任何代码；

第一条规定举个简略的例子即可：

var a stringfunc f() {    fmt.Println(a) // (1)}func hello() {    a = "hello, world" // (2)    go f() // (3)}

因为goroutine的创立 happens-before 其执行，所以(3) happens-before (1)，又因为天然执行的规定(2) happens-before (3)，依据传递性，所以(2) happens-before (1)，这样保障了咱们每次打印进去的都是"hello world"而不是空字符串。

第二条规定是少见的否定句式，同样举个简略的例子：

var a stringfunc hello() {    go func() { a = "hello" }() // (1)    fmt.Println(a) // (2)}

因为goroutine的实现不保障happens-before任何代码，因而(1) happens-before (2)不成立，这样咱们就不能保障每次打印的后果都是"hello"。

通道

通道channel是go语言中用于goroutine之间通信的次要渠道，因而了解通道之间的happens-before规定也至关重要。

1.对于缓冲通道，向通道发送数据happens-before从通道接管到数据

联合一个例子：

var c = make(chan int, 10)var a stringfunc f() {    a = "hello, world" // (1)    c <- 0 // (2)}func main() {    go f() // (3)    <-c // (4)    fmt.Println(a) // (5)}

c是一个缓冲通道，因而向通道发送数据happens-before从通道接管到数据，也就是(2) happens-before (4)，再联合天然执行规定以及传递性不难推导出(1) happens-before (5)，也就是打印的后果保障是"hello world"。
乏味的是，如果咱们把c的定义改为var c = make(chan int)也就是无缓冲通道，下面的论断就不存在了（注1），打印的后果不肯定为"hello world"，这是因为：

2.对于无缓冲通道，从通道接收数据happens-before向通道发送数据

咱们能够将上述例子略微调整下：

var c = make(chan int)var a stringfunc f() {    a = "hello, world" // (1)    <- c // (2)}func main() {    go f() // (3)    c <- 10 // (4)    fmt.Println(a) // (5)}

对于无缓冲通道，(2) happens-before (4)，再依据传递性，(1) happens-before (5)，因而仍然能够保障打印的后果是"hello world"。

能够这么了解这两者的差别，缓冲通道的目标是缓冲发送方发送的数据，这就意味着发送方很可能先发送数据，过一段时间后接管刚才接管，或者发送方发送的速度超过接管方接管的速度，因为缓冲通道的发送happens-before接管就自然而然了；相同，非缓冲通道是没有缓冲区的，先发动的发送方和接管方都会阻塞至另一方筹备好，如果咱们应用了非缓冲通道，则意味着咱们认为咱们的场景下接管产生在发送之前，否则咱们就会应用缓冲通道了，因而非缓冲通道的接管happens-before发送。

3.对于缓冲通道，第k次接管happens-before第k+C次发送，C是缓冲通道的容量

这条规定是缓冲通道的通用规定（乏味的是，下面针对非缓冲通道的第2条规定也能够看成这个规定的特例：C取0）。这个规定看起来简单，咱们看个例子就清晰了：

var limit = make(chan int, 3)func main() {    // work是一个worker列表，其中的元素w都是可执行函数    for _, w := range work {        go func(w func()) {            limit <- 1 // (1)            w() // (2)            <-limit // (3)        }(w)    }    select{}}

咱们先套用一下下面的规定，则：“第1次(3)happens-before第4次(1)”、“第2次(3)happens-before第5次(1)”、“第3次(3)happens-before第6次(1)”……，再联合传递性：“第1次(2)happens-before第1次(3)happens-before第4次(1)happens-before第4次(2)”、“第2次(2)happens-before第2次(3)happens-before第5次(1)happens-before第5次(2)”……，简略地说：“第1次(2)happens-before第4次(2)”、“第2次(2)happens-before第5次(2)”、“第3次(2)happens-before第6次(2)”……这样咱们尽管没有做任何分批，却事实上将workers分成三个一批、每批并发地执行。这就是通过这条happens-before规定保障的。

这个规定了解起来其实也很简略，C是通道的容量，如果无奈保障第k次接管happens-before第k+C次发送，那通道的缓冲就不够用了。

注1：以上是官网文档给的规定和例子，然而笔者在尝试将第一个例子的c改成无缓冲通道后发现每次打印的仍然稳固是"hello world"，并没有呈现预期的空字符串，也就是看起来happens-before规定仍然成立。但既然官网文档说无奈保障，那咱们开发时还是依照happens-before不成立比拟好。

锁

锁也是并发编程里十分罕用的一个数据结构。go语言中反对的锁次要有两种：sync.Mutex和sync.RWMutex，即一般锁和读写锁（读写锁的原理能够参见另一篇文章）。一般锁的happens-before规定也很直观：

1.对锁实例调用n次Unlock happens-before 调用Lock m次，只有n < m

请看这个例子：

var l sync.Mutexvar a stringfunc f() {    a = "hello, world" // (1)    l.Unlock() // (2)}func main() {    l.Lock() // (3)    go f() // (4)    l.Lock() // (5)    print(a) // (6)}

下面调用了Unlock一次，Lock两次，因而(2) happens-before (5)，从而(1) happens-before (6)

而读写锁的规定为：

2.对读写锁实例的某一次Unlock调用，happens-after的RLock调用对应的RUnlock调用happens-before下一次Lock调用。

其实实质就是读写锁的原理：读写互斥，简略地了解就是写锁开释后先获取了读锁，则读锁的开释会happens-before 下一次写锁的获取。留神下面的规定是“存在”，而不是“任意”。

Once

sync中还提供了一个Once的数据结构，用于管制并发编程中只执行一次的逻辑，例如：

var a stringvar once sync.Oncefunc setup() {   a = "hello, world"   fmt.Println("set up")}func doprint() {   once.Do(setup)   fmt.Println(a)}func twoprint() {    go doprint()    go doprint()}

会打印"hello, world"两次和"set up"一次。Once的happens-before规定也很直观：

第一次执行Once.Do happens-before其余的Once.Do

利用

把握了上述的根本happens-before规定，能够联合起来剖析更简单的场景了，来看这个例子：

var a, b intfunc f() {    a = 1 // (1)    b = 2 // (2)}func g() {    print(b) // (3)    print(a) // (4)}func main() {    go f()    g()}

这里(1) happens-before (2)，(3) happens-before(4)，然而(1)与(3)、(4)之间以及(2)与(3)、(4)之间并没有happens-before关系，这时候后果是不确定的，一种乏味的后果是2、0，也就是(1)、(2)之间产生了指令重排序。当初让咱们批改一下下面的代码，让它按咱们预期的逻辑运行：要么打印0、0，要么打印1、2。

应用锁

var a, b intvar lock sync.Mutexfunc f() {    lock.Lock() // (1)    a = 1 // (2)    b = 2 // (3)    lock.Unlock() // (4)}func g() {    lock.Lock() // (5)    print(b) // (6)    print(a) // (7)    lock.Unlock() // (8)}func main() {    go f()    g()}

回忆下锁的规定：

1.对锁实例调用n次Unlock happens-before 调用Lock m次，只有n < m

这里存在两种可能：要么(4) happens-before (5)，要么(8) happens-before (1)，会别离推导出两种后果：(6) happens-before (7) happens-before (2) happens-before (3) ，以及(2) happens-before (3) happens-before (6) happens-before (7)，也就别离对应“0、0”和“1、2”两种后果。

应用通道

var a, b intvar c = make(chan int, 1)func f() {   <- c   a = 1 // (2)   b = 2 // (3)   c <- 1}func g() {   <- c   print(b) // (6)   print(a) // (7)   c <- 1}func test() {   wg := sync.WaitGroup{}   wg.Add(3)   go func(){      defer wg.Done()      f()   }()   go func(){      defer wg.Done()      g()   }()   go func(){      defer wg.Done()      c <- 1   }()   wg.Wait()   close(c)}

总之，如果无奈确定并发读写之间的happens-before关系，那么最好应用同步工具明确它们之间的关系，例如锁或者通道。不要给程序留下不确定的可能，毕竟确定性就是编程的魅力！