golang学习笔记 ---面向并发的内存模型

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

Go语言是
基于消息并发模型的集大成者，它将基于CSP模型的并发编程内置到了语言中，通
过一个go关键字就可以轻易地启动一个Goroutine，与Erlang不同的是Go语言的
Goroutine之间是共享内存的。

Goroutine和系统线程

Goroutine是Go语言特有的并发体，是一种轻量级的线程，由go关键字启动。在真
实的Go语言的实现中，goroutine和系统线程也不是等价的。尽管两者的区别实际
上只是一个量的区别，但正是这个量变引发了Go语言并发编程质的飞跃。

系统线程

每个系统级线程都会有一个固定大小的栈（一般默认可能是2MB），这个栈
主要用来保存函数递归调用时参数和局部变量。

固定了栈的大小导致了两个问题：
一是对于很多只需要很小的栈空间的线程来说是一个巨大的浪费，二是对于少数需
要巨大栈空间的线程来说又面临栈溢出的风险。针对这两个问题的解决方案是：要
么降低固定的栈大小，提升空间的利用率；要么增大栈的大小以允许更深的函数递
归调用，但这两者是没法同时兼得的。

Goroutine

相反，一个Goroutine会以一个很小的栈启动

（可能是2KB或4KB），当遇到深度递归导致当前栈空间不足时，Goroutine会根据
需要动态地伸缩栈的大小（主流实现中栈的最大值可达到1GB）。

因为启动的代价
很小，所以我们可以轻易地启动成千上万个Goroutine。

Go的运行时还包含了其自己的调度器，这个调度器使用了一些技术手段，可以在n
个操作系统线程上多工调度m个Goroutine。Go调度器的工作和内核的调度是相似
的，但是这个调度器只关注单独的Go程序中的Goroutine。Goroutine采用的是半抢
占式的协作调度，只有在当前Goroutine发生阻塞时才会导致调度；同时发生在用户
态，调度器会根据具体函数只保存必要的寄存器，切换的代价要比系统线程低得
多。运行时有一个 runtime.GOMAXPROCS 变量，用于控制当前运行正常非阻塞
Goroutine的系统线程数目。

在Go语言中启动一个Goroutine不仅和调用函数一样简单，而且Goroutine之间调度
代价也很低，这些因素极大地促进了并发编程的流行和发展。

原子操作

所谓的原子操作就是并发编程中“最小的且不可并行化”的操作。通常，如果多个并
发体对同一个共享资源进行的操作是原子的话，那么同一时刻最多只能有一个并发
体对该资源进行操作。从线程角度看，在当前线程修改共享资源期间，其它的线程
是不能访问该资源的。原子操作对于多线程并发编程模型来说，不会发生有别于单
线程的意外情况，共享资源的完整性可以得到保证。

一般情况下，原子操作都是通过“互斥”访问来保证的，通常由特殊的CPU指令提供
保护。当然，如果仅仅是想模拟下粗粒度的原子操作，我们可以借助
于 sync.Mutex 来实现：

package mainimport (
"fmt"
"sync"
)var total struct {
sync.Mutex
value int
}func worker(wg *sync.WaitGroup) {
defer wg.Done()
for i := 0; i <= 100; i++ {
total.Lock()
total.value += i
total.Unlock()
}
}
func main() {
var wg sync.WaitGroup
wg.Add(2)
go worker(&wg)
go worker(&wg)
wg.Wait()
fmt.Println(total.value)
}

在 worker 的循环中，为了保证 total.value += i 的原子性，我们通
过 sync.Mutex 加锁和解锁来保证该语句在同一时刻只被一个线程访问。对于多
线程模型的程序而言，进出临界区前后进行加锁和解锁都是必须的。如果没有锁的
保护， total 的最终值将由于多线程之间的竞争而可能会不正确。

用互斥锁来保护一个数值型的共享资源，麻烦且效率低下。标准库
的 sync/atomic 包对原子操作提供了丰富的支持。我们可以重新实现上面的例
子：

package mainimport (
"fmt"
"sync"
"sync/atomic"
)var total uint64func worker(wg *sync.WaitGroup) {
defer wg.Done()
var i uint64
for i = 0; i <= 100; i++ {
atomic.AddUint64(&total, i)
}
}
func main() {
var wg sync.WaitGroup
wg.Add(2)
go worker(&wg)
go worker(&wg)
wg.Wait()
fmt.Println(total)}

atomic.AddUint64 函数调用保证了 total 的读取、更新和保存是一个原子操
作，因此在多线程中访问也是安全的。

原子操作配合互斥锁可以实现非常高效的单件模式。互斥锁的代价比普通整数的原
子读写高很多，在性能敏感的地方可以增加一个数字型的标志位，通过原子检测标
志位状态降低互斥锁的使用次数来提高性能。

顺序一致性内存模型

package mainvar a string
var done boolfunc setup() {
a = "hello, world"
done = true
}
func main() {
go setup()
for !done {
}
print(a)
}

我们创建了 setup 线程，用于对字符串 a 的初始化工作，初始化完成之后设
置 done 标志为 true 。 main 函数所在的主线程中，通过 for !done {} 检
测 done 变为 true 时，认为字符串初始化工作完成，然后进行字符串的打印工
作。

但是Go语言并不保证在 main 函数中观测到的对 done 的写入操作发生在对字符
串 a 的写入的操作之后，因此程序很可能打印一个空字符串。更糟糕的是，因为
两个线程之间没有同步事件， setup 线程对 done 的写入操作甚至无法
被 main 线程看到， main 函数有可能陷入死循环中。

在Go语言中，同一个Goroutine线程内部，顺序一致性内存模型是得到保证的。但
是不同的Goroutine之间，并不满足顺序一致性内存模型，需要通过明确定义的同步
事件来作为同步的参考。如果两个事件不可排序，那么就说这两个事件是并发的。
为了最大化并行，Go语言的编译器和处理器在不影响上述规定的前提下可能会对执
行语句重新排序（CPU也会对一些指令进行乱序执行）。

因此，如果在一个Goroutine中顺序执行 a = 1; b = 2; 两个语句，虽然在当前的
Goroutine中可以认为 a = 1; 语句先于 b = 2; 语句执行，但是在另一个
Goroutine中 b = 2; 语句可能会先于 a = 1; 语句执行，甚至在另一个Goroutine
中无法看到它们的变化（可能始终在寄存器中）。也就是说在另一个Goroutine看
来, a = 1; b = 2; 两个语句的执行顺序是不确定的。如果一个并发程序无法确
定事件的顺序关系，那么程序的运行结果往往会有不确定的结果。比如下面这个程
序

package main

func main() {

go println("你好, 世界")

}

根据Go语言规范， main 函数退出时程序结束，不会等待任何后台线程。因为
Goroutine的执行和 main 函数的返回事件是并发的，谁都有可能先发生，所以什
么时候打印，能否打印都是未知的。

用前面的原子操作并不能解决问题，因为我们无法确定两个原子操作之间的顺序。
解决问题的办法就是通过同步原语来给两个事件明确排序：

package mainfunc main() {
done := make(chan int)
go func() {
println("你好, 世界")
done <- 1
}()
<-done
}

当 <-done 执行时，必然要求 done <- 1 也已经执行。根据同一个Gorouine依然
满足顺序一致性规则，我们可以判断当 done <- 1 执行时， println("你好, 世
界") 语句必然已经执行完成了。因此，现在的程序确保可以正常打印结果。

当然，通过 sync.Mutex 互斥量也是可以实现同步的：

package mainimport "sync"func main() {
var mu sync.Mutex
mu.Lock()
go func() {
println("你好, 世界")
mu.Unlock()
}()
mu.Lock()
}

可以确定后台线程的 mu.Unlock() 必然在 println("你好, 世界") 完成后发生
（同一个线程满足顺序一致性）， main 函数的第二个 mu.Lock() 必然在后台线
程的 mu.Unlock() 之后发生（ sync.Mutex 保证），此时后台线程的打印工作已
经顺利完成了。