Go中的内存顺序保证

package main

import "log"
import "runtime"

var a string
var done bool

func setup() {
    a = "hello, world"
    done = true
    if done {
        log.Println(len(a)) // 如果被打印出来，它总是12
    }
}

func main() {
    go setup()

    for !done {
        runtime.Gosched()
    }
    log.Println(a) // 期待的打印结果：hello, world
}

此程序的行为很可能正如我们所料，hello, world将被打印输出。 然而，此程序的行为并非跨编译器和跨平台架构兼容的。 如果此程序使用一个不同的（但符合Go规范的）编译器或者不同的编译器版本编译，它的运行结果可能是不同的。 即使此程序使用同一个编译器编译，在不同的平台架构上的运行结果也可能是不同的。

编译器和CPU可能调整setup函数中的前两条语句的执行顺序，使得setup协程中的指令的执行顺序和下面的代码指定的顺序一致。

func setup() {
    done = true
    a = "hello, world"
    if done {
        log.Println(len(a))
    }
}

var x, y int
func f1() {
    x, y = 123, 789
    go func() {
        fmt.Println(x)
        go func() {
            fmt.Println(y)
        }()
    }()
}

然而这些顺序在下面这个函数中是得不到任何保证的。此函数存在着数据竞争。

var x, y int
func f2() {
    go func() {
        fmt.Println(x) // 可能打印出0、123，或其它值
    }()
    go func() {
        fmt.Println(y) // 可能打印出0、789，或其它值
    }()
    x, y = 123, 789
}

下面列出的是通道操作做出的基本顺序保证：

1. 一个通道上的第n次成功发送操作的开始发生在此通道上的第n次成功接收操作完成之前，无论此通道是缓冲的还是非缓冲的。
2. 一个容量为m通道上的第n次成功接收操作的开始发生在此通道上的第n+m次发送操作完成之前。 特别地，如果此通道是非缓冲的（m == 0），则此通道上的第n次成功接收操作的开始发生在此通道上的第n次发送操作完成之前。
3. 一个通道的关闭操作发生在任何因为此通道被关闭而从此通道接收到了零值的操作完成之前。

事实上， 对一个非缓冲通道来说，其上的第n次成功发送的完成的发送和其上的第n次成功接收的完成应被视为同一事件。

下面这段代码展示了一个非缓冲通道上的发送和接收操作是如何保证特定的代码执行顺序的。

func f3() {
    var a, b int
    var c = make(chan bool)

    go func() {
        a = 1
        c <- true
        if b != 1 {
            panic("b != 1") // 绝不可能发生
        }
    }()

    go func() {
        b = 1
        <-c
        if a != 1  {
            panic("a != 1") // 绝不可能发生
        }
    }()
}

对于函数f3中创建的两个协程，下列顺序将得到保证：

• 赋值语句b = 1肯定在条件b != 1被估值之前执行完毕。
• 赋值语句a = 1肯定在条件a != 1被估值之前执行完毕。

所以，上例代码中两个协程中的panic调用将永不可能得到执行。
做为对比，下面这段代码中的panic调用有可能会得到执行，因为上述通道操作相关的顺序保证对于不相关的协程是无效的。

func f4() {
    var a, b, x, y int
    c := make(chan bool)

    go func() {
        a = 1
        c <- true
        x = 1
    }()

    go func() {
        b = 1
        <-c
        y = 1
    }()

    // 一个和上面的通道操作不相关的协程。
    // 这是一个不良代码的例子，它造成了很多数据竞争。
    go func() {
        if x == 1 {
            if a != 1 {
                panic("a != 1") // 有可能发生
            }
            if b != 1 {
                panic("b != 1") // 有可能发生
            }
        }

        if y == 1 {
            if a != 1 {
                panic("a != 1") // 有可能发生
            }
            if b != 1 {
                panic("b != 1") // 有可能发生
            }
        }
    }()
}

这里的新创建的第三个协程是一个和通道c上的发送和接收操作不相关的一个协程。 它所观察到的执行顺序和其它两个新创建的协程可能是不同的。 条件a != 1和b != 1的估值有可能为true，所以四个panic调用有可能会得到执行。

事实上，大多数编译器的实现确实很可能能够保证上面这个不良的例子中的四个panic调用永远不可能被执行，但是，没有任何Go官方文档做出了这样的保证。 此不良例子的执行结果是依赖于不同的编译器和不同的编译器版本的。 我们编写的Go代码应该以Go官方文档中明确记录下来的规则为依据。

下面是一个缓冲通道的例子。

func f5() {
    var k, l, m, n, x, y int
    c := make(chan bool, 2)

    go func() {
        k = 1
        c <- true
        l = 1
        c <- true
        m = 1
        c <- true
        n = 1
    }()

    go func() {
        x = 1
        <-c
        y = 1
    }()
}

在此例子中，下面的顺序得以保证：

• 赋值语句k = 1的执行保证在赋值语句y = 1的执行之前结束。
• 赋值语句x = 1的执行保证在赋值语句n = 1的执行之前结束。

然而，赋值语句x = 1的执行并不能保证在赋值语句l = 1和m = 1的执行之前结束， 赋值语句l = 1和m = 1的执行也不能保证在赋值语句y = 1的执行之前结束。

下面是一个通道关闭的例子。在这个例子中，赋值语句k = 1的执行保证在赋值语句y = 1执行之前结束，但不能保证在赋值语句x = 1执行之前结束。

func f6() {
    var k, x, y int
    c := make(chan bool, 1)

    go func() {
        c <- true
        k = 1
        close(c)
    }()

    go func() {
        <-c
        x = 1
        <-c
        y = 1
    }()
}

1. 对于一个可寻址的sync.Mutex类型或者sync.RWMutex类型的值m，第n次成功的m.Unlock()方法调用保证发生在第n+1次m.Lock()方法调用返回之前。
2. 对一个可寻址的RWMutex类型值rw，如果它的第n次rw.Lock()方法调用已成功返回，并且有一个rw.RLock()方法调用保证发生在此第n次rw.Lock()方法调用返回之后，则第n次成功的rw.Unlock()方法调用保证发生在此rw.RLock()方法调用返回之前。
3. 对一个可寻址的RWMutex类型值rw，如果它的第n次rw.RLock()方法调用已成功返回，并且有一个rw.Lock()方法调用保证发生在此第n次rw.RLock()方法调用返回之后，则第m次成功的rw.RUnlock()方法调用（其中m <= n）保证发生在此rw.Lock()方法调用返回之前。

在下面这个例子中，下列顺序肯定得到保证。

• 赋值语句a = 1的执行保证在赋值语句b = 1的执行之前结束。
• 赋值语句m = 1的执行保证在赋值语句n = 1的执行之前结束。
• 赋值语句x = 1的执行保证在赋值语句y = 1的执行之前结束。

func fab() {
    var a, b int
    var l sync.Mutex // or sync.RWMutex

    l.Lock()
    go func() {
        l.Lock()
        b = 1
        l.Unlock()
    }()
    go func() {
        a = 1
        l.Unlock()
    }()
}

func fmn() {
    var m, n int
    var l sync.RWMutex

    l.RLock()
    go func() {
        l.Lock()
        n = 1
        l.Unlock()
    }()
    go func() {
        m = 1
        l.RUnlock()
    }()
}

func fxy() {
    var x, y int
    var l sync.RWMutex

    l.Lock()
    go func() {
        l.RLock()
        y = 1
        l.RUnlock()
    }()
    go func() {
        x = 1
        l.Unlock()
    }()
}

注意，在下面这段代码中，根据Go官方文档，赋值语句p = 1的执行并不能保证在赋值语句q = 1的执行之前结束，尽管多数编译器确实能够做出这样的保证。

var p, q int
func fpq() {
    var l sync.Mutex
    p = 1
    l.Lock()
    l.Unlock()
    q = 1
}

没有任何官方文档提到了原子操作所保证的内存顺序。 然而，事实上，对于标准编译器来说，原子操作确实保证了某些特定的内存顺序。 标准库的实现大量地依赖于这些原子操作做出的内存顺序保证。

下面这个程序如果使用标准编译器1.15编译的话，它在运行时肯定打印出1。

package main

import "fmt"
import "sync/atomic"
import "runtime"

func main() {
    var a, b int32 = 0, 0

    go func() {
        atomic.StoreInt32(&a, 1)
        atomic.StoreInt32(&b, 1)
    }()

    for {
        if n := atomic.LoadInt32(&b); n == 1 {
            fmt.Println(atomic.LoadInt32(&a)) // 1
            break
        }
        runtime.Gosched()
    }
}

在此程序中，主协程总是会观察到对a的修改在对b的修改之前结束。 但是，这种保证没有记录在任何Go官方文档中。 如果你希望你编写的Go代码能够跨编译器和跨编译器版本兼容，那么安全的建议是不要依赖于原子操作做出的内存顺序保证。 有一个issue建议Go官方文档将目前原子操作做出的内存顺序保证记录下来。 但是到目前为止（Go 1.15），此建议还未被采纳。

请阅读原子操作一文来获取如何使用原子操作。