很多编译器优化(在编译时刻)和CPU处理器优化(在运行时刻)会常常调整指令执行顺序,从而使得指令执行顺序和代码中指定的顺序不太一致。 指令顺序也称为内存顺序。
当然,指令执行顺序的调整规则不是任意的。 最基本的要求是发生在一个不与其它协程共享数据的协程内部的指令执行顺序调整在此协程内部必须不能被觉察到。 换句话说,从这样的一个协程的角度看,其中的指令执行顺序和代码中指定的顺序总是一致的,即使确实有一些指令的执行顺序发生了调整。
然而,如果一些协程之间共享数据,那么在其中一个协程中发生的指令执行顺序调整将有可能被剩余的其它协程觉察到,从而影响到所有这些协程的行为。 在并发编程中,多个协程之间共享数据是家常便饭。 如果我们忽视了指令执行顺序调整带来的影响,我们编写的并发程序的行为将依赖于特定编译器和CPU。这样的程序常常表现出异常行为。
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规范的)编译器或者不同的编译器版本编译,它的运行结果可能是不同的。
即使此程序使用同一个编译器编译,在不同的平台架构上的运行结果也可能是不同的。
setup
函数中的前两条语句的执行顺序,使得setup
协程中的指令的执行顺序和下面的代码指定的顺序一致。
func setup() {
done = true
a = "hello, world"
if done {
log.Println(len(a))
}
}
setup
协程并不会觉察到此执行顺序调整,所以此协程中的log.Println(len(a))
语句将总是打印出12
(如果此打印语句在程序退出之前得到了执行的话)。
但是,此执行顺序调整将被主协程觉察到,所以最终的打印结果有可能是空,而不是hello, world
。
除了没有考虑指令执行顺序调整带来的影响,此程序还存在数据竞争的问题。
变量a
和done
的使用没有进行同步。
所以此程序是一个充满了各种并发编程错误的不良例子。
一个职业的Go程序员不应该写出这样的使用于生产环境中的代码。
我们可以使用Go官方工具链中的go build -race
命令来编译并运行一个程序,以检查此程序中是否存在着数据竞争。
有时,为了程序的逻辑正确性,我们需要确保一个协程中的一些语句一定要在另一个协程的某些语句之后(或者之前)执行(从这两个协程的角度观察都是如此)。 指令执行顺序调整可能会给此需求带来一些麻烦。 我们应如何防止某些可能发生的指令执行顺序调整呢?
不同的CPU架构提供了不同的栅栏(fence)指令来防止各种指令执行顺序调整。 一些编程语言提供对应的函数来在代码中的合适位置插入各种栅栏指令。 但是,理解和正确地使用这些栅栏指令极大地提高了并发编程的门槛。
Go语言的设计哲学是用尽量少的易于理解的特性来支持尽量多的使用场景,同时还要尽量保证代码的高执行效率。 所以Go内置和标准库并没有提供直接插入各种栅栏指令的途径。 事实上,这些栅栏指令被使用在Go中提供的各种高级数据同步技术的实现中。 所以,我们应该使用Go中提供的高级数据同步技术来保证我们所期待的代码执行顺序。
本文的余下部分将列出Go中保证的各种代码执行顺序。 这些顺序保证可能在Go 1 内存模型一文提到了,也可能没有提到。
在下面的叙述中,如果我们说事件A
保证发生在事件B
之前,这意味着这两个事件涉及到的任何协程都将观察到在事件A
之前的语句肯定将在事件B
之后的语句先执行。
对于不相关的协程,它们所观察到的顺序可能并非如此所述。
x
和y
的赋值保证发生在对它们的打印之前,并且对x
的打印肯定发生在对y
的打印之前。
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
}
m == 0
),则此通道上的第n次成功接收操作的开始发生在此通道上的第n次发送操作完成之前。
事实上, 对一个非缓冲通道来说,其上的第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
}()
}
sync.Mutex
类型或者sync.RWMutex
类型的值m
,第n次成功的m.Unlock()
方法调用保证发生在第n+1次m.Lock()
方法调用返回之前。
RWMutex
类型值rw
,如果它的第n次rw.Lock()
方法调用已成功返回,并且有一个rw.RLock()
方法调用保证发生在此第n次rw.Lock()
方法调用返回之后,则第n次成功的rw.Unlock()
方法调用保证发生在此rw.RLock()
方法调用返回之前。
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
}
sync.WaitGroup
值做出的顺序保证
假设在某个给定时刻,一个可寻址的sync.WaitGroup
值wg
维护的计数不为0,并且有一个wg.Wait()
方法调用在此给定时刻之后调用。
如果有一组wg.Add(n)
方法调用在此给定时刻之后调用,并且我们可以保证这组调用中只有最后一个返回的调用会将wg
维护的计数修改为0,
则这组调用中的每个调用保证都发生在此wg.Wait()
方法调用返回之前。
注意:调用wg.Done()
和wg.Add(-1)
是等价的。
请阅读对sync.WaitGroup
类型的解释来获取如何使用sync.WaitGroup
值。
sync.Once
值做出的顺序保证
请阅读对sync.Once
类型的解释来获取sync.Once
值做出的顺序保证和如何使用sync.Once
值。
sync.Cond
值做出的顺序保证
sync.Cond
值出的顺序保证有些难以表达清楚。所以这里就只可意会不可言传了。
请阅读对sync.Cond
类型的解释来获取如何使用sync.Cond
值。
从Go 1.19开始,Go 1 内存模型正式地说明Go程序中执行的原子操作按照顺序一致次序(sequentially consistent order)执行。 如果一个原子(写)操作A的效果被一个原子(读)操作B观察到,则A肯定被同步到B之前执行。
按照这个说法,在下面这个程序中,对变量b
的原子写操作肯定发生在对其读取结果为1
的原子原子读操作之前。
从而使得对变量a
的普通写操作也发生于对其的普通读操作之前。
所以此程序保证会打印出2
。
package main
import (
"fmt"
"runtime"
"sync/atomic"
)
func main() {
var a, b int32 = 0, 0
go func() {
a = 2
atomic.StoreInt32(&b, 1)
}()
for {
if n := atomic.LoadInt32(&b); n == 1 {
fmt.Println(a) // 2
break
}
runtime.Gosched()
}
}
请阅读原子操作一文来获取如何使用原子操作。
runtime.SetFinalizer(x, f)
发生在终结调用f(x)
被执行之前。
Go101.org网站内容包括Go编程各种相关知识(比如Go基础、Go优化、Go细节、Go实战、Go测验、Go工具等)。后续将不断有新的内容加入。敬请收藏关注期待。
本丛书微信公众号(联系方式一)名称为"Go 101"。二维码在网站首页。此公众号将时不时地发表一些Go语言相关的原创短文。各位如果感兴趣,可以搜索关注一下。
《Go语言101》系列丛书项目目前托管在Github上(联系方式二)。欢迎各位在此项目中通过提交bug和PR的方式来改进完善《Go语言101》丛书中的各篇文章。我们可以在项目目录下运行go run .
来浏览和确认各种改动。
本书的twitter帐号为@Golang_101(联系方式三)。玩推的Go友可以适当关注。
你或许对本书作者老貘开发的一些App感兴趣。