第 11 章同步原语与模式 on Go 语言原本

11.1 共享内存式同步模式

Mon, 01 Jan 0001 00:00:00 +0000

11.1 共享内存式同步模式

程序的构造可以用更简单的基础原语来表达，这一事实是一个有力的保障：这些原语所包含的内容，能与程序语言的其余部分在逻辑上保持一致。 —— C. A. R. Hoare

并发编程的全部困难，可以浓缩成一句话：多个执行单元要在同一份状态上协作，而它们各自推进的次序无法预知。如何让这种协作既正确又高效，半个多世纪以来分化出两条大的传统。本章讲的是其中一条，共享内存。在拆解 Go 标准库 sync 与 sync/atomic 里那些具体原语之前，本节先把这两条传统放在一起辨认清楚，说明它们为何是对偶的，再交代 Go 在其间所站的位置。读懂了这层取舍，后面 11.2 到 11.9 各节就不再是孤立的 API，而是同一种设计哲学落到不同场景上的样子。

11.1.1 并发的两大传统

并发编程历史上有两条大的传统。一条是共享内存：线程共享地址空间，靠互斥锁、信号量、条件变量等手段协调对共享状态的访问。Dijkstra 1965 年提出的信号量与 Hoare 1974 年提出的监管程（monitor）是它的奠基石，它也是 C/C++、Java、以及几乎所有操作系统内核的主流路数。另一条是 消息传递：执行单元不共享状态，只通过收发消息协调。Hoare 的 CSP（10.1）与 Hewitt 的 Actor 模型是它的两支，Erlang、occam 是它的代表。

两条传统的分野，落在「状态归谁所有」这一点上。共享内存里状态是公有的，谁都能碰，于是必须靠锁划出临界区，规定同一时刻只许一个执行单元进入；消息传递里状态是私有的，别人想读写只能发一封信请它代劳，协调由信道的收发时序天然完成。

flowchart LR
    subgraph SM["共享内存"]
        direction TB
        T1["线程 1"] --> L["锁 / 临界区"]
        T2["线程 2"] --> L
        L --> S["共享状态"]
    end
    subgraph MP["消息传递"]
        direction TB
        A1["执行单元 1"] -->|"消息"| CH["信道"]
        CH -->|"消息"| A2["执行单元 2<br/>(私有状态)"]
    end

值得一提的是，两者并非非此即彼。Dijkstra 当年用信号量解的「生产者与消费者」「哲学家就餐」等问题，今天用 channel 同样能写；反过来，channel 的内部实现本身就是一段被互斥锁保护的共享缓冲（10）。这种「换一种说法就能从一边翻译到另一边」的观感并非错觉，下一小节会看到，它早在 1979 年就被证明是一条普遍规律。

11.2 互斥锁

Mon, 01 Jan 0001 00:00:00 +0000

11.2 互斥锁

sync.Mutex 是最朴素的同步原语：同一时刻只让一个 goroutine 进入临界区。朴素的接口之下，它要在两个互相拉扯的目标间反复权衡，吞吐（让锁尽快被某人拿走，别让 CPU 闲着）与公平（别让某个倒霉的等待者永远排不到队）。这两者无法同时拉满：把锁严格按到达次序移交，最公平，却要为每次交接付一次上下文切换；放任刚醒来的与正在跑的自由竞争，最快，却可能让某个等待者一次次落空。这一节先把互斥这个古老问题的理论与硬件地基铺开，再看 Go 的 mutex 如何在这条钢丝上行走。

11.2.1 互斥问题与它的硬件地基

互斥是并发理论最早的课题之一。Dijkstra 于 1965 年形式化了「互斥问题」，并给出第一个不借助任何硬件特殊指令、仅凭普通读写就能让多个进程轮流进入临界区的软件解。其后 Lamport 于 1974 年的 面包店算法（bakery algorithm）把这条路走到了一个漂亮的终点：每个想进临界区的线程先「取号」，再按号码从小到大依次进入，既保证互斥，又保证先到先得的公平排队，而全程只用普通读写，不需要任何原子读改写指令。

纯软件解在理论上自足，工程上却昂贵：面包店算法要遍历所有线程的号码，开销随线程数增长，且严重依赖顺序一致的内存模型（11.9），在现代弱序硬件上还得另加屏障。因此现代锁不再走纯软件这条路，而是直接站在硬件提供的原子读改写指令之上，比较并交换（compare-and-swap, CAS）、取后加（fetch-and-add）等（11.3）。一条 CAS 就能原子地完成面包店算法要好几步才能模拟的事，地基一换，上层设计随之改观。

围绕这些原语，锁长出了一个谱系，理解它有助于看清 Go 的 mutex 站在哪里。

自旋锁（spin lock）最简单：用一个 CAS 反复试，抢到就进，抢不到就原地空转再试。它在低竞争下近乎零成本，但高竞争下是灾难：多个核心争同一个锁变量，每次 CAS 都让那条缓存行在核心之间来回失效、重取，称为缓存行弹跳（cache-line bouncing），竞争者越多越糟。
票号锁（ticket lock）用 fetch-and-add 发号，再让每个线程自旋等自己的号被叫到，由此恢复了 FIFO 公平。但所有等待者仍然自旋在同一个「当前服务号」变量上，缓存行弹跳的老问题并未根除。
MCS 锁（Mellor-Crummey 与 Scott，1991）是高扩展性锁的经典之作。它让每个等待者把自己挂进一条显式队列，并各自自旋在自己的本地变量上，前一个持锁者释放时只去写后继者的那个本地变量。如此一来，无论多少竞争者，每次交接只触动一条缓存行，竞争下的缓存流量降到常数。

以上都是「忙等」一脉，等待者占着 CPU 空转。另一条线把「睡眠等待」做廉价。早年线程要阻塞只能陷入内核，即便锁根本没有竞争也要付系统调用的代价。Linux 的 futex（fast userspace mutex， Franke、Russell 与 Kirkwood，2002）解决了这个痛点：无竞争时加解锁纯在用户态用一次原子操作完成，只有真要阻塞或唤醒等待者时，才带着那个用户态地址陷入内核去排队。几乎所有现代用户态锁，包括 Go 的 mutex，都踩在 futex（及各平台的等价物）这块「用户态快、内核态兜底」的地基上。Go 自己不直接调 futex，而是由运行时的信号量（runtime_SemacquireMutex / runtime_Semrelease）封装各平台的底层阻塞原语，对上层呈现统一接口。

11.3 原子操作

Mon, 01 Jan 0001 00:00:00 +0000

11.3 原子操作

sync/atomic 是 Go 同步原语里最贴近硬件的一层。互斥锁（11.1）、channel （8）这些更高层的工具，内部都建立在原子操作之上。它提供「不可分割」的读写与读改写：一个原子操作要么完整发生、要么没发生，中间不会被别的 goroutine 看到一半。但原子操作的意义远不止「防撕裂」。它是无锁编程的地基，而无锁编程背后，有一套关于「哪些原语能做什么」的深刻理论，那是本节真正想讲清的东西。

本节先把基本操作摆出来，落到 CAS 这块基石；再退后一步，借 Herlihy 的共识层级回答「为什么是 CAS」；接着进入无锁的暗礁 ABA 与内存回收，说明 Go 为何把硬的无锁结构留在运行时内部；最后回到工程，讲 sync/atomic 的顺序一致承诺，以及 Go 1.19 那次把「该用原子访问」编进类型的演进。

11.3.1 几种基本操作

原子操作的家族不大：Load（原子读）、Store（原子写）、Add（原子增减）、Swap（原子交换）、 CompareAndSwap（比较并交换，CAS），以及 Go 1.23 起补齐的 And/Or（原子位运算）。它们都落到单条带 LOCK 前缀的 CPU 指令上：x86 上 CAS 是 LOCK CMPXCHG，ARMv8 上是 LDXR/STXR 的 load-linked / store-conditional 重试对，加法是 LOCK XADD。换言之，原子性的最终保证来自硬件， sync/atomic 只是把这些指令包装成可移植的 Go 函数。

其中 CAS 是无锁编程的基石。它原子地完成「如果当前值还是我以为的那个，就改成新值，否则什么都不做并告诉我失败」：

// CompareAndSwap 的语义（伪代码，整体不可分割地执行）
func CompareAndSwapInt64(addr *int64, old, new int64) (swapped bool) {
    if *addr == old {
        *addr = new
        return true
    }
    return false
}

为什么单单一个 CAS 就够撑起无锁？因为几乎所有无锁算法都能写成同一种骨架，一个重试循环：读出当前值，据它算出想要的新值，再用 CAS 把它写回去；只有「这期间没人动过」时 CAS 才成功，否则拿到的就是别人更新后的值，重来一遍即可。

11.4 条件变量

Mon, 01 Jan 0001 00:00:00 +0000

11.4 条件变量

互斥锁（11.2）回答的是「谁能进临界区」，条件变量回答的则是另一个问题：「一个 Goroutine 已经进了临界区，却发现现在还不能干活，它该如何等到能干活的那一刻，同时把临界区让给别人」。生产者消费者是最常见的例子。队列满时，生产者既不能写入，又不能一直攥着锁空转，否则消费者永远拿不到锁去腾空间，于是双方一起卡死。条件变量 sync.Cond 给出的办法是：让生产者「带锁睡去」，原子地交出锁并阻塞，等消费者腾出空间后把它唤醒，醒来时锁又回到它手上。

这一节先把用法讲清楚，尤其是那条几乎所有教材都强调、却很少解释清楚来由的规矩： Wait 必须写在 for 循环里。这条规矩不是 Go 的发明，它根植于 1970 年代关于「管程」（monitor）的两种唤醒语义之争。讲清这段历史，读者就会明白为什么从 pthread 到 Java 再到 Go，现代条件变量无一例外地要求循环复查。随后我们给出 Go 实现的速写（notifyList 的 ticket 机制、禁止拷贝的 copyChecker），最后说明一个也许出乎意料的事实：在 Go 里 sync.Cond 其实很少用， channel 与 close 广播大多把它取代了。

11.4.1 用法：Wait 为何要写在 for 循环里

先看一段标准的生产者消费者。condition 是受锁保护的共享状态，cond 用同一把锁构造：

func main() {
	cond := sync.NewCond(new(sync.Mutex))
	condition := 0

	// 消费者
	go func() {
		for {
			cond.L.Lock()
			for condition == 0 { // 没有可消费的，带锁睡去
				cond.Wait()
			}
			condition--
			cond.Signal() // 腾出了空间，唤醒一个生产者
			cond.L.Unlock()
		}
	}()

	// 生产者
	for {
		cond.L.Lock()
		for condition == 100 { // 队列满了，带锁睡去
			cond.Wait()
		}
		condition++
		cond.Signal() // 有货了，唤醒一个消费者
		cond.L.Unlock()
	}
}

Wait 的契约是三步合一：原子地解锁 c.L、阻塞当前 Goroutine、被唤醒后重新锁上 c.L 再返回。「原子地解锁并阻塞」是关键的一步，它堵死了一个否则必然出现的丢失唤醒窗口：若先解锁、再阻塞分作两步，解锁之后阻塞之前的那一瞬，另一方完全可能改好条件并发出 Signal，而此刻还没睡着的本方收不到这个信号，待它睡去便再无人来唤，于是永久错过。 Wait 把解锁与入队做成一体，正是为了消除这个窗口。

11.5 同步组

Mon, 01 Jan 0001 00:00:00 +0000

11.5 同步组

前几节的互斥锁（11.2）与条件变量（11.4）解决的是「多个 Goroutine 争用同一份共享状态」的问题。本节要谈的 sync.WaitGroup 解决的是另一类问题：一个 Goroutine 派生出若干子任务，然后等它们全部完成再继续。前者是争用，后者是汇合。这是并发编程里最常见的一种结构，称为 fork-join，而 WaitGroup 正是 Go 标准库给它的答案。

11.5.1 屏障与闩锁的谱系

在认识 WaitGroup 的实现之前，先把它放进同步原语的谱系里，看清它解决的是哪一类问题。等待「一组事件全部发生」这件事，并发文献里有一个专门的家族，叫屏障（barrier）与闩锁（latch）。家族里的几位成员形态各异，Java 的 java.util.concurrent 把它们分得相当清楚，正好用来定位 WaitGroup：

原语	形态	可复用	计数是否可动态增减
`CountDownLatch`（Java）	一群等待者等计数减到 0，一次性	否	否，构造时定死
`CyclicBarrier`（Java）	$N$ 个对等方互相等齐，到齐后自动重置	是	否，参与方数目固定
`Phaser`（Java）	分阶段屏障，参与方可中途注册 / 注销	是	是
`sync.WaitGroup`（Go）	一方等一组任务全部完成，fork-join	是（Wait 返回后）	是（Add 可正可负）

WaitGroup 最接近 CountDownLatch：都是「计数从某个正值减到 0，等待者随之放行」。区别在两处。其一，CountDownLatch 的计数在构造时定死，WaitGroup 的计数靠 Add 动态累加，这点更像 Phaser 的注册机制。其二，CountDownLatch 是一次性的，减到 0 便报废，而 WaitGroup 在一轮 Wait 返回后可以重新使用。

11.6 缓存池

Mon, 01 Jan 0001 00:00:00 +0000

11.6 缓存池

频繁地分配又丢弃同一类临时对象，会给垃圾回收器（13）带来沉重压力。 sync.Pool 提供一条出路：把用完的对象暂存起来、下次复用，而不是每次都新分配。它的典型用法是缓冲区、序列化器这类"用完即弃、又反复要用"的临时对象。

var bufPool = sync.Pool{New: func() any { return new(bytes.Buffer) }}

b := bufPool.Get().(*bytes.Buffer)
b.Reset()           // 取回的对象可能是脏的，先重置
// ... 使用 b ...
bufPool.Put(b)      // 用完放回，供他人复用

New 是唯一需要用户提供的字段：当池里取不到对象时，由它兜底造一个。于是 Get 拿到的，要么是别人刚用完放回的旧对象，要么是 New 现造的新对象，调用方无从、也不应区分二者。本节先讲它复用对象的古老思路，再拆开它为并发与 GC 所做的三层设计：每 P 分片、victim 缓存、以及与运行时 GC 的协同。

11.6.1 对象复用：一个古老的内存技巧

“预先备好一批对象、反复借还而非频繁创建销毁”，是内存管理里很古老的思路,空闲列表（free list，12.2）、对象池（object pool）、slab 分配器（Bonwick 1994，内核用它缓存固定类型的对象）都是它的化身。其价值有二：省去重复的分配与初始化开销;以及,对带 GC 的语言尤其重要,减少活跃对象的产生速率，从而降低 GC 频率与停顿。

这第二点正是 sync.Pool 文档里写的本分,“缓存已分配但暂未使用的对象以备复用，为垃圾回收器减压”。要看清这层减压从何而来，可把 Go 的并发标记清扫（13）粗略记成工作量与活跃对象数成正比：标记阶段要遍历可达对象、清扫阶段要回收死对象。每次 New 一个临时对象、用完即弃，都是在给堆增加一个"生而即死"的对象，抬高分配速率，进而更频繁地触发 GC、每轮 GC 要扫的对象也更多。复用把这批对象从"反复生死"变成"借了又还"，既压低了分配速率，也让它们不再每轮都成为 GC 的扫描与回收对象。fmt 包就是教科书式的例子：它用一个 sync.Pool 维护临时输出缓冲，并发打印多时缓冲池自动变大，空闲时随 GC 收缩。它把这个古老技巧做成了并发安全、且与 Go GC 协同的标准件。需要强调的是它的边界：池是对 GC 压力的优化，不是托管对象生命周期的容器。一个只在某个短命对象内部维护的 free list 不该用 sync.Pool,文档明确指出，那种场景下让对象自带 free list 更划算，因为 Pool 的分摊收益建立在"被一个包的众多并发使用者静默共享"之上，单点使用摊不开它的固定开销。

11.7 并发安全散列表

Mon, 01 Jan 0001 00:00:00 +0000

11.7 并发安全散列表

sync.Map 在 Go 1.24 经历了一次彻底的内部重写：原先的 read/dirty 双 map 设计被换成一个并发散列字典树（hash-trie）。本节先把这两代设计各自的来由讲清楚，再把它们放回并发散列表的解法谱系里。

语言内建的 map 不是并发安全的。多个 Goroutine 在没有同步的前提下同时读写同一个 map，运行时会主动探测到并发访问并以 fatal error: concurrent map read and map write 终止进程（5.2 介绍过这个检测机制，它是不可恢复的，recover 拦不住）。对可用性有要求的服务，这是一处必须正面回答的设计问题：当多个 Goroutine 要共享一张表，应当用什么结构。

最朴素的答案是给一张普通 map 套一把锁：

// 一张普通 map 加一把读写锁，是最直接、也最常够用的并发安全表
type RWMutexMap struct {
	mu   sync.RWMutex
	data map[any]any
}

func (m *RWMutexMap) Load(k any) (v any, ok bool) {
	m.mu.RLock()
	v, ok = m.data[k]
	m.mu.RUnlock()
	return
}

func (m *RWMutexMap) Store(k, v any) {
	m.mu.Lock()
	m.data[k] = v
	m.mu.Unlock()
}

这套写法简单、类型安全（键值类型由你自己定），在多数场景下也足够快。它的瓶颈只在一处：所有读都要竞争同一把锁。RWMutex 允许多个读者并发持锁，但持锁本身要更新读者计数，这是一次对共享缓存行的原子写，核数一多就成为争用点（11.2 讲过这件事）。sync.Map 要解决的，正是这个「读多到锁本身都嫌贵」的场景。在看它怎么做之前，先把整张解法地图铺开。

11.8 上下文

Mon, 01 Jan 0001 00:00:00 +0000

11.8 上下文

一个进入服务器的请求，往往不会只在一个 goroutine 里走完。它会扇出（fan-out）成一棵 goroutine 树：查数据库的、调下游 RPC 的、读缓存的，各自再派生出更小的工作。一旦请求的发起方不再需要结果，比如客户端断开了连接，或上游已超时，这整棵树上仍在运行的工作就成了纯粹的浪费，占着连接、锁与内存，却没有人会去读它们的产出。于是问题变成：怎样把「到此为止」这个信号，从树根一路传播到每一片叶子，让它们各自停下来。

context 包就是 Go 对这个问题给出的标准答案。它把取消、截止时间与请求范围内的元数据，沿着调用链显式传递，使一棵 goroutine 树可以被统一地取消。本节先说清它为什么是协作式而非强制式的，再沿取消树的结构走一遍实现，最后把它放进结构化并发与跨语言的谱系里来看。

11.8.1 为什么取消是信号，而非强制

最朴素的想法，是给 goroutine 一个「杀掉它」的 API。Go 偏偏没有这样的 API，这不是疏漏，而是从前人的教训里学来的设计。

Java 早年提供过 Thread.stop()，能从外部强行终止一个线程。它在 JDK 1.2 就被废弃，原因写在官方的废弃说明里：被停止的线程会立刻抛出 ThreadDeath，并释放它当时持有的所有监视器锁。锁是用来保护一段不变式的，持锁线程被半路打断、锁却被放开，意味着其他线程会看到一个处于中间状态、不变式被破坏的共享对象，而且毫无征兆。后来的 JDK 干脆让 Thread.stop() 直接抛 UnsupportedOperationException，把这扇门彻底关上。强制终止之所以危险，根子在于外部无从知道目标此刻是否正处在某个不可被打断的临界区里。

Go 由此选择了相反的路：运行时不提供「杀死一个 goroutine」的手段，取消是一个信号，由 goroutine 自己在安全的检查点去查看、再自行决定如何收尾。撤销、回滚、释放资源，这些只有代码自己知道怎么做对，于是就交还给代码自己做。

在有 context 之前，这个信号可以用一个 channel 手写出来。关闭一个 channel 会唤醒所有在它上面等待的接收者（10.4），这正是「广播一次取消」的天然载体：

cancel := make(chan struct{})

go func() {
	done := make(chan struct{}, 1)
	go func() {
		defer func() { done <- struct{}{} }()
		do() // 执行需要执行的操作
	}()
	select {
	case <-cancel:
		// 提前被取消：等已启动的工作收尾，再撤销其副作用
		<-done
		undo()
	case <-done:
		// 顺利结束
	}
}()

// 出于某些原因希望取消
close(cancel)

这段代码已经含着 context 的全部要点：取消方只负责发信号（close(cancel)），被取消方在 select 里把取消信号与正常完成并列等待，收到信号后在自己选定的安全点收尾。context 做的，是把这套手写模式抽象成一个接口，并解决一个手写版没有解决的问题：当工作扇出成一棵树时，如何让一次取消沿树自动传播到每一个后代。

11.9 内存一致模型

Mon, 01 Jan 0001 00:00:00 +0000

11.9 内存一致模型

Go 的内存模型在 2022 年随 Go 1.19 做过一次重要修订，本节在讲清当前模型之后，会专门交代这次修订的来龙去脉（见 11.9.8）。

读者或许注意到，在此前关于 Go 运行时与编译器的讨论中，我们一直回避着一个话题： Go 的内存模型。回避并非无故。要讲清楚它，需要并发、同步原语乃至硬件层面的铺垫，而这些铺垫至此方才齐备。作为本章的收尾，亦是全书对 Go 同步原语与同步模式的总结，我们在此展开这一话题，回答读者心中那个尚未解开的疑问：两个 Goroutine 同时读写同一变量时，一方的写入在何种条件下才保证为另一方所见。

11.9.1 内存模型的重要性

内存一致模型，或称内存模型，是一份契约，立于语言用户与语言自身、语言与操作系统平台、操作系统平台与硬件平台之间。它界定并行之下读写时序得以确定的条件，回答这样一个问题：某个共享变量是否具备足够的同步，使一个线程的写入能为另一个线程的读取所见。

一份 Go 程序写成之后，要先后经过编译器的转换与优化、运行其上的操作系统或虚拟机等动态优化器，以及 CPU 对指令流的优化，方能执行。其中任何一个环节，都可能调整某个变量读写的次序，使其偏离程序员写下的顺序。没有内存模型作保障，便无从推演程序最终执行时是否正确。

内存模型的取舍影响深远，关乎程序的可移植性与可维护性。过强的模型压缩硬件与编译器的优化空间，压低性能上限；一种已选定强模型的硬件体系结构，又难以在不破坏兼容性的前提下转向更弱的模型，而破坏兼容性的代价，是要求其上的程序重写源码。

横跨用户、软件与硬件三方，使内存模型的设计格外棘手，至今仍是开放的研究问题。讨论 Go 的内存模型之前，我们先了解既有的内存模型，以及软硬件之间历次立约的经验与教训。

为使「顺序被调整」一事具体可见，考虑一段最小的生产者与消费者程序。它们共享 data 与 done，一个写入数据并置位标志，另一个等待标志置位后读取数据：

var data int
var done bool

func producer() {
	data = 42      // (1)
	done = true    // (2)
}

func consumer() {
	for !done {    // (3)
	}
	print(data)    // (4)
}

源代码中 (1) 写在 (2) 之前，直觉上 consumer 一旦读到 done == true，便应当读到 data == 42。然而这段程序并不保证打印 42，也可能停在循环中不再退出。前文所说的三道优化，在此各显其形：编译器可将无依赖的 (1) 与 (2) 互换，或将循环中对 done 的读取提升至循环外，使其反复读取同一寄存器中的旧值；CPU 以乱序方式发射指令，只为单个核心维持其自身可见的数据依赖；写入还会先停留在核心私有的存储缓冲（store buffer）中，何时对其他核心可见，由缓存一致性协议决定，与写入的先后未必一致。

第 11 章 同步原语与模式 on Go 语言原本

11.1 共享内存式同步模式

11.1 共享内存式同步模式

11.1.1 并发的两大传统

11.2 互斥锁

11.2 互斥锁

11.2.1 互斥问题与它的硬件地基

11.3 原子操作

11.3 原子操作

11.3.1 几种基本操作

11.4 条件变量

11.4 条件变量

11.4.1 用法：Wait 为何要写在 for 循环里

11.5 同步组

11.5 同步组

11.5.1 屏障与闩锁的谱系

11.6 缓存池

11.6 缓存池

11.6.1 对象复用：一个古老的内存技巧

11.7 并发安全散列表

11.7 并发安全散列表

11.8 上下文

11.8 上下文

11.8.1 为什么取消是信号，而非强制

11.9 内存一致模型

11.9 内存一致模型

11.9.1 内存模型的重要性

第 11 章同步原语与模式 on Go 语言原本