关于golang:Go的内存模型

这篇文章次要是为了浏览这篇文档作的笔记，解释了什么状况下一个 goroutine 对变量写的值能被另一个 goroutine 牢靠察看到，次要以义译为主，文中括号内容均为我集体了解。

无论是用单个通道来守护并发数据的实现还是应用 sync 和 sync/atomic 中的同步原语的实现，程序中多个 goroutine 并发拜访雷同数据时这些拜访肯定是串行的。(两种常见的并发模型: 应用专门 channel 来操作并发拜访的数据，其它 goroutine 把本人的操作申请发给这个 channel；多个 goroutine 抢锁来操作数据)

在单个 goroutine 中，对一个变量读写操作的真正执行程序必须要和代码中的程序具备雷同的执行成果，就是说，编译器和处理器可能会对单个 goroutine 内的一些读写操作进行 从新排序 ，但调整程序前后的执行后果不能跟按代码中的程序执行后果不统一。因为存在这种从新排序，一个 goroutine 中的代码所展现的执行程序和其它 goroutine 理论察看 (比方另一个 goroutine 监听这个 goroutine 变量的变动) 到的这个 goroutine 的执行程序可能会不同。比方一个 goroutine 代码中是顺次执行 a=1 和 b=2，另一个 goroutine 可能 会察看到 b 先被赋值为 2，而后再是 a=1。

为了说分明读和写的申请，先定义一下这个 happens before : 用来表白 Go 程序在内存中的一小段执行程序，当咱们说 e1 在 e2 之前产生时, 就是在说 e2 在 e1 之后产生。当 e1 没有产生在 e2 之前，而且 e2 没有产生在 e1 之后时，咱们说 e1 和 e2 这时是并发的 (即咱们无奈牢靠判断 e1 和 e2 的执行程序)。

在单个 goroutine 内, happens before 的程序是由代码表白的程序决定的

对于变量 v 的一个读 r，如果 能够察看到 （注: 绝对于 牢靠察看到 更弱一些 ) 写 w 对 v 的操作，那么 r 和 w 要满足：

1. r 不能产生在 w 之前(即 r，w 要么并发产生，要么 r 在 w 之后产生)
2. 在 w 之后且在 r 之前没有其余的对 v 的写 (即其它的写要么与 w 并发产生，要么与 r 并发产生，要么产生在 w 之前，要么产生在 r 之后)

而如果为了保障对 v 的读 r 可能察看到对 v 特定的一次写 w，就是说要 r 仅察看到这特定的一次 w , 为了实现 r 可能 牢靠察看 到这次 w，那要满足:

1. w 产生在 r 之前 (相比前文两条束缚排除了 r，w 并发产生)
2. 其它任何对共享变量 v 的写，要么产生在 w 之前，要么产生在 r 之后 (相比前文的两条束缚排除了其它的写与 w 并发产生，和与 r 并发产生两种状况)

上面这对束缚要强于下面那对，因为上面这对明确要求在 w 和 r 产生时没有其它的 w 并发产生。在单个 goroutine 内是不可能并发的，所以单个 goroutine 的状况下下面两对束缚是一个意思：对 v 的读可能察看到最近一次的 w。然而在多个 goroutine 共享 v 的状况下, 就必须应用同步原语建设牢靠的 happens-before 来保障一次读可能取到指定的一次写。

应用 v 类型的零值对 v 进行初始化和一次对 v 的写操作，在内存模型中是一样的

对于一个超过一个字（即机器字）的值来说，对它的读写操作相当于多个不确定程序的单字操作

同步中的 happens before:

几种牢靠的产生程序

1. 如果 p 导入 q 包, 那么 q 的 init 函数是牢靠产生在 p 中任何逻辑之前的
2. 而 main 包中 main 函数是牢靠产生在所有 init 函数之后的
3. goroutine 创立时的 go 申明牢靠产生在这个 goroutine 开始执行之前

var a string
func f() {print(a)
}
func hello() {a = "hello, world"   # a 是被先赋值, go f()后执行, 所以 print(a)肯定会打印 "hello,world"
        go f()}

1. 不实用同步机制的话, 无奈可靠保证 goroutine 的退出绝对于程序中任何事件的先或者后

var a string
func hello() {go func() {a = "hello"}()
        print(a)   # 这能够打印空字符串, 也能够打印 hello, 甚至一些激进的编译器间接删除后面的 go
}

通道通信中的 happens before:

通道通信是次要的 goroutine 之间的同步机制, 每个通道有对应的发送方和接管方, 通常发送和接管会在不同的 goroutine

1. 一次发送牢靠产生在对应这次发送的接管实现之前

var c = make(chan int, 10)
var a string
func f() {
        a = "hello, world"
        c <- 0
}
func main() {go f()
        <-c
        print(a)  # 这个肯定牢靠打印 hello, world, 因为 main 中 <- c 接管实现之前,c<- 0 肯定牢靠产生, 那么对 a 的写肯定也牢靠产生 
}

1. 通道敞开牢靠产生在接受方收到通道类型的零值之前, 下面 c <- 0 改为 close(c)是雷同的成果
2. 对于无缓冲通道的接管是牢靠产生在发送实现之前

var c = make(chan int)
var a string
func f() {
        a = "hello, world"
        <-c
}
func main() {go f()
        c <- 0
        print(a)  # c 的发送产生在 print 之前, 
}

1. 第 k 次对容量为 C 的缓冲通道的接管是牢靠产生在第 k + C 次的发送实现之前

注: 这个地位须要比照 5, 7, 8 了解一下,
文档原文如下:

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.

前两句比拟好了解, 重点是 3,4 两句对于非缓冲通道和缓冲通道满了状况的形容比拟令人费解, 另一篇介绍通道的文档中有这一段

If the channel is unbuffered, the sender blocks until the receiver has received the value. If the channel has a buffer, the sender blocks only until the value has been copied to the buffer; if the buffer is full, this means waiting until some receiver has retrieved a value.

如果是无缓冲通道, 发送者会始终阻塞到接收者接管实现这个值. 如果是缓冲通道, 发送者会始终阻塞直到值被复制到缓冲区, 如果缓冲区满了, 那就要等接收者从缓冲区中取走一个值。

这段介绍和 3,4 的论断是统一的, 即对于阻塞状态下的通道, 无论是无缓冲通道还是缓冲通道满了, 接管实现肯定是先于发送实现的, 这里始终应用的是 has received 和 has retrieved, 对应 3,4 中的 completes, 所以发送这个行为或者是先产生的, 但最终实现, 肯定是接管先实现, 而后发送才实现.

另外, 这段话还提供了缓冲通道的细节: 把发送者期待的是把值复制到缓冲区, 而不是接收者实现, 接收者期待的是缓冲区的值, 所以对于缓冲未满的状况, 发送者要先实现把值复制到缓冲区, 接收者能力从缓冲区读到值, 就是 1 的论断, 而非缓冲通道发送者期待的是接收者实现.(这细节有卵用, 可能是晓得从阻塞状态下通道解阻塞后, 接收者先走一步，但两者处于不同 goroutine, 后续各自的代码执行先后还是未知的????)

两种通道时序图简略画一下吧

ok, 接着读这篇内存模型的文档

通过第八条论断, 能够用缓冲通道来模仿计数型的同步机制: 缓冲数代表最大容许的沉闷同步量的数量, 达到数量之后, 如果还想应用同步量就要期待其它沉闷的同步量被开释, 罕用来限度并发, 上代码：

var limit = make(chan int, 3)
func main() {
    for _, w := range work {    # 尽管 for 为每个 work 创立了一个 goroutine, 但这些 goroutine 并不是同时沉闷的   
        go func(w func()) {  
            limit <- 1          # limit 满了状况下, goroutine 就会阻塞在这里
            w()
            <- limit            # 直到其它 goroutine 执行完 w(), 从 limit 中取一个值进去, 达到限度任何时候最大沉闷 goroutine 只有 3}(w)
    }
}

锁中的 happens before:

1. 对于 sync.Mutex 或者 sync.RWMutex 类型变量 l(小写 L), n, m 其中 n <m, n 次对 l.Unlock()牢靠产生在 m 次的 l.Lock()之前

var l sync.Mutex
var a string
func f() {
    a = "hello"
    l.Unlock()   # n = 1}
func main() {l.lock()  # m = 1 
    go f()
    l.lock()  # m = 2 下面 n = 1 牢靠产生在 m = 2 之前, 所以对 a 的写产生在 m = 2 之前, m= 2 产生在 print 之前, 所以对 a 的写产生在 print 之前, 牢靠打印 hello
    print(a)
}

1. 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. 这句意思是下图

Once 中的 happens before:

1. Once 提供了并发场景下的初始化计划, 多个 goroutine 调用 once.Do(f), 仅会有一个真正执行了 f(), 其它的 goroutine 会阻塞期待执行的那个返回, 即其中一个真正执行的那个 goroutine 执行 f()会产生在任何一 once.Do(f)返回之前

var a string
var once sync.Once
func setup() {a = "hello"}
func doprint() {once.Do(setup)
    print(a)
}
func twoprint() {go doprint()     # 这两个 goroutine 中仅有一个真正执行了 setup()，然而两个都会阻塞到 setup()被执行实现
    go doprint()     # 所以 a 写入产生在 once.Do(setup)之前，print(a)会牢靠打印两遍 hello
}

不正确的同步:

var a, b int
func f() {
    a = 1
    b = 2
}
func g() {print(b)
    print(a)
}
func main() {go f()
    g()    # 这个地位简直可 print 任何组合, 0-0, 0-1, 2-0, 1-2, 因为 f 的 goroutine 和主 goroutine 没有任何同步，}

var a string
var done bool

func setup() {
    a = "hello"
    done = true
}
func doprint() {
    if !done {          # 重点是, 这个逻辑是在暗示读到了 done 就能读到在 done 之前写的 a, 实际上是，在没有同步机制下，读到了 done 也不肯定
        once.Do(setup)  # 能读到 a      
    }
    print(a)
}
func twoprint() {go doprint()    # 可能两个 goroutine 都会阻塞在 once.Do(setup)地位, 其中一个真正执行了 setup, 而另一个不会执行, 这个为执行的 goroutine
    go doprint()    # 就无奈牢靠察看到那个执行 setup 的 goroutine 对 a 的写, 所以会有一个空字符串}

var a string
var done bool

func setup() {
    a = "hello"
    done = true
}
func main() {go setup()
    for !done {}    # 这个也是在暗示读到 done 就能读到 a, 同样这个 done 可能被 main goroutine 读到, 但不肯定示意就能读到 a, 还有就是这个 done
    print(a)        # 也有可能永远不会被 main 读到,
}

type T struct {msg string}
var g *T
func setup() {t := new(T)
    t.msg = "hello"
    g = t
}
func main() {go setup()
    for g == nil {}    # main gorotine 和 setup gorotine 共享了 g, 所以 main 能够察看到 g, 然而对 g.msg 的写无奈可靠保证。print(g.msg)
}

只有显式应用同步原语就能够解决下面的问题