乐趣区

关于golang:白话Go内存模型HappenBefore

jiezi

来自公众号：Gopher 指北

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

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

Happens Before

在单 goroutine 中，读取和写入的行为肯定是和程序指定的执行程序体现统一。换言之，编译器和处理器在不扭转语言标准所定义的行为前提下才能够对单个 goroutine 中的指令进行重排序。

a := 1
b := 2

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

var a, b int
// goroutine A
go func() {
    a := 5
    b := 1
}()
// goroutine B
go 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 string
var 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

退出移动版