Go语言的内存模型是什么

Go语言的内存模型是什么

今天就跟大家聊聊有关Go语言的内存模型是什么，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

Go 内存模型规定了一些条件，在这些条件下，在一个 goroutine 中读取变量返回的值能够确保是另一个 goroutine 中对该变量写入的值。

Happens Before（在…之前发生）

在一个 goroutine 中，读操作和写操作必须表现地就好像它们是按照程序中指定的顺序执行的。这是因为，在一个 goroutine 中编译器和处理器可能重新安排读和写操作的执行顺序（只要这种乱序执行不改变这个 goroutine 中在语言规范中定义的行为）。

a = 1; b = 2;

为了规定读取和写入的必要条件，我们定义了 happens before （在…之前发生），一个在 Go 程序中执行内存操作的部分顺序。如果事件 e1 发生在事件 e2 之前，那么我们说 e2 发生在 e1 之后。同样，如果 e1 不在 e2 之前发生也不在 e2 之后发生，那么我们说 e1 和 e2 同时发生。

在一个单独的 goroutine 中，happens-before 顺序就是在程序中的顺序。

一个对变量 v 的 读操作 r 可以被允许观察到一个对 v 的写操作 w，如果下列条件同时满足：

r 不在 w 之前发生在 w 之后，r 之前，没有其他对 v 的写入操作 w' 发生。

为了确保一个对变量 v 的读操作 r 观察到一个对 v 的 写操作 w，必须确保 w 是唯一的 r 允许的写操作。就是说下列条件必须同时满足：

w 在 r 之前发生任何其他对共享的变量 v 的写操作发生在 w 之前或 r 之后。

这两个条件比前面两个条件要严格，它要求不能有另外的写操作与 w 或 r 同时发生。

在一个单独的 goroutine 中，没有并发存在，所以这两种定义是等价的：一个读操作 r 观察到的是最近对 v 的写入操作 w 。当多个 goroutine 访问一个共享的变量 v 时，它们必须使用同步的事件来建立 happens-before 条件来确保读操作观察到预期的写操作。

在内存模型中，使用零值初始化一个变量的 v 的行为和写操作的行为一样。

读取和写入超过单个机器字【32 位或 64 位】大小的值的行为和多个无序地操作单个机器字的行为一样。

同步

初始化

程序初始化操作在一个单独的 goroutine 中运行，但是这个 goroutine 可能创建其他并发执行的 goroutines。

如果包 p 导入了包 q，那么 q 的 init 函数执行完成发生在 p 的任何 init 函数执行之前。

函数 main.main【也就是 main 函数】 的执行发生在所有的 init 函数完成之后。

Goroutine 创建

启动一个新的 goroutine 的 go 语句的执行在这个 goroutine 开始执行前发生。

比如，在这个程序中：

调用 hello 函数将会在之后的某个事件点打印出 “hello, world”。【因为 a = “hello, world” 语句在 go f() 语句之前执行，而 goroutine 执行的函数 f 在 go f() 语句之后执行，a 的值已经初始化了 】

Goroutine 销毁

goroutine 的退出不保证发生在程序中的任何事件之前。比如，在这个程序中：

a 的赋值之后没有跟随任何同步事件，所以不能保证其他的 goroutine 能够观察到赋值操作。事实上，一个激进的编译器可能删除掉整个 go 语句。

如果在一个 goroutine 中赋值的效果必须被另一个 goroutine 观察到，那么使用锁或者管道通信这样的同步机制来建立一个相对的顺序。

管道通信

管道通信是在 goroutine 间同步的主要方法。一个管道的发送操作匹配【对应】一个管道的接收操作（通常在另一个 goroutine 中）。

一个在有缓冲的管道上的发送操作在相应的接收操作完成之前发生。

这个程序：

能够确保输出 “hello, world”。因为对 a 的赋值操作在发送操作前完成，而接收操作在发送操作之后完成。

关闭一个管道发生在从管道接收一个零值之前。

c <- 0close(c)

一个在无缓冲的管道上的接收操作在相应的发送操作完成之前发生。

这个程序 （和上面一样，使用无缓冲的管道，调换了发送和接收操作）：

也会确保输出 “hello, world”。

c = make(chan int, 1)"hello, world"

在一个容量为 C 的管道上的第 k 个接收操作在第 k+C 个发送操作完成之前发生。

该规则将前一个规则推广到带缓冲的管道。它允许使用带缓冲的管道实现计数信号量模型：管道中的元素数量对应于正在被使用的数量【信号量的计数】，管道的容量对应于同时使用的最大数量，发送一个元素获取信号量，接收一个元素释放信号量。这是一个限制并发的常见用法。

limit

锁

syncsync.Mutexsync.RWMutex

sync.Mutexsync.RWMutexll.Unlock()l.Lock()

这个程序：

"hello, world"

Once

syncOnce

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

在这个程序中：

调用 twoprint 只会调用 setup 一次。setup 函数在调用 print 函数之前完成。结果将会打印两次"hello, world"。

不正确的同步

注意到一个读操作 r 可能观察到与它同时发生的写操作w 写入的值。当这种情况发生时，那也不能确保在 r 之后发生的读操作能够观察到在 w 之前发生的写操作。

在这个程序中：

可能会发生函数 g 输出 2 然后 0 的情况。【b 的值输出为2，说明已经观察到了 b 的写入操作。但是之后读取 a 的值却为 0，说明没有观察到 b 写入之前的 a 写入操作！不能以为 b 的值是 2，那么 a 的值就一定是 1 ！】

这个事实使一些常见的处理逻辑无效。

比如，为了避免锁带来的开销，twoprint 那个程序可能会被不正确地写成：

这样写不能保证在 doprint 中观察到了对 done 的写入。这个版本可能会不正确地输出空串。

另一个不正确的代码逻辑是循环等待一个值改变：

和之前一样，在 main 中，观察到了对 done 的写入并不意味着观察到了对 a 的写入，所以这个程序可能也会打印一个空串。更糟糕的是，不能够保证对 done 的写入会被 main 观察到，因为两个线程间没有同步事件。 在 main 中的循环不能确保会完成。

类似的程序如下：

即使 main 观察到了 g != nil，退出了循环，也不能确保它观察到了 g.msg 的初始值。

在所有这些例子中，解决方法都是相同的：使用显示地同步。