第 10 章通道与 select on Go 语言原本

10.1 通道与 CSP 的工程化

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

10.1 通道与 CSP 的工程化

本节内容提供一个线上演讲：YouTube 在线， Google Slides 讲稿。

CSP 给了 Go 一个主张：进程之间不共享状态，只靠传递消息来协调（1.3）。这一节关心的是另一个问题：一门工程语言要把这个主张落地，需要把「通信」做成什么样子，才能让普通程序员顺手用对。Go 的答案是 channel，一个一等的同步兼通信原语。本节先把它在语言表层的模型讲清楚，它的类型、收发语法、有无缓冲的两种语义、方向限定与 nil 行为，为后续各节深入运行时实现（10.2–10.7）铺好直觉。

10.1.1 把通信做成一等原语

「不要以共享内存的方式通信，而要以通信的方式共享内存。」这句格言常被引用，但它在 Go 里不是一句口号，而是由 channel 这个具体的语言构造兑现的。CSP 的渊源、它与 1978 年原始论文的异同，已在 1.3 交代，这里不再重复，只接着说 Go 在工程上做了什么取舍。

把 CSP 的「通信」搬进一门通用语言，至少要回答三件事：通信经由什么载体、这个载体能否像普通值一样使用、它如何与类型系统咬合。Go 给出的载体是 channel，并且把它做成了一等（first-class）的：channel 是有类型的值，可以由 make 创建、用变量持有、作为参数传给函数、作为返回值传出、存进结构体字段、放进 slice 或 map。这一点与 Hoare 原始 CSP 按进程名直接通信的设计不同（1.3.2），也正是 Go 把抽象主张变为可组合工具的关键: 既然 channel 是值，「把一个通信端口交给另一段代码」就退化成了普通的传参，无需任何特殊机制。

channel 同时承担两件常被分开的事:同步与数据传递。一次收发既搬运了一个值，又在收发双方之间建立了一个发生序（happens-before）关系，后者保证了「发送方在发送前写下的内存，接收方在接收后一定看得见」。换句话说，channel 不仅是一根传值的管子，它还是同步原语。这条发生序保证是 channel 能替代显式加锁的根基，其精确条文留待 10.6 与 11.9 展开，本节只需记住:收发自带同步。

10.2 hchan：通道的内部结构

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

10.2 hchan：通道的内部结构

10.1 从 CSP 的角度交代了通道在语言里的位置：它是显式的消息信道，把「通信」与「同步」合二为一。这一节把它拆开来看。一个 channel 在运行时里就是一个名为 hchan 的结构体，它的全部秘密不过是一把锁、一圈环形缓存、外加两条等待队列。结构虽小，每个字段的存在都对应一处设计上的考量，读懂这几样东西，后面收发与 select 的全部逻辑（10.3– 10.6）就只是「在这张图上搬运数据、挂起与唤醒 goroutine」。

沿用本书讲运行时数据结构的惯例，下文给出的结构体是裁剪后的速写，只留与设计相关的字段，并在注释里说明它为何存在。完整定义可对照 runtime/chan.go 与 runtime/runtime2.go。

10.2.1 三条不变式：先看「为什么」

在逐字段拆解之前，先抄下 chan.go 开头那段注释立下的三条不变式，它们是整套结构的设计意图，比任何字段说明都更能说清「为何如此」：

c.sendq 与 c.recvq 至少有一个为空（唯一的例外是：一个无缓冲 channel 上，某个 goroutine 用 select 同时在收和发两侧挂着）；
对缓冲 channel，c.qcount > 0 蕴含 c.recvq 为空；
对缓冲 channel，c.qcount < c.dataqsiz 蕴含 c.sendq 为空。

这三条用日常语言说就是一句话：缓存里还有货，就不该有接收方在干等；缓存还有空位，就不该有发送方在干等。 一旦缓存与「干等的人」同时存在，说明本可以直接成交却没成交，那是 bug。整个收发实现（10.3、10.4）所做的，正是时刻维持这三条：能直接成交就直接成交，实在成交不了才把自己挂进等待队列。带着这个意图回看下面的字段，就不再是枯燥的清单。

10.2.2 hchan 的速写

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// hchan：一个 channel 的运行时表示（速写）
type hchan struct {
 qcount uint // 缓存中现有的元素个数
 dataqsiz uint // 环形缓存的容量（make 的第二个参数）
 buf unsafe.Pointer // 指向一段可存 dataqsiz 个元素的连续数组
 elemsize uint16 // 单个元素的大小（由元素类型推出，缓存于此免去反复查表）
 closed uint32 // 是否已 close
 elemtype *_type // 元素类型：拷贝元素、写屏障、给 buf 标注 GC 信息都要用它
 sendx uint // 环形缓存的写游标（下一个待写入的槽）
 recvx uint // 环形缓存的读游标（下一个待读出的槽）
 recvq waitq // 阻塞的接收方队列（ <-ch ）
 sendq waitq // 阻塞的发送方队列（ ch<- ）

 lock mutex // 一把锁，守护以上所有字段
}

字段大体分作三组。qcount、dataqsiz、buf、sendx、recvx 五个合起来描述那圈环形缓存 （10.2.3）；recvq、sendq 是两条等待队列（10.2.4）；closed 记录关闭状态， elemsize 与 elemtype 是为搬运元素备下的元信息。其中 dataqsiz 在创建之后再不写入，因此运行时可以无锁地读它来快速判断 channel 是否有缓存（full 等辅助函数依赖这一点）。至于 elemtype，它不只用于按值拷贝元素和触发写屏障，还在创建时被交给分配器，用来给 buf 标注「这段内存里哪些位置是指针」，这一点到 10.2.5 会再回来。（go1.26 的 hchan 还有 timer 与 bubble 两个字段，分别服务于 time 定时器与 testing/synctest，与本节的主线无关，速写中略去。）

10.3 收发与直接传递

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

10.3 收发与直接传递

本节内容对标 Go 1.26。

10.2 把 hchan 这副骨架摆了出来：一把锁、一个环形缓存 buf，外加发送方队列 sendq 与接收方队列 recvq。这一节让骨架动起来，回答一次 ch <- v 与 v := <-ch 在运行时里究竟发生了什么。读懂这条收发路径，channel 的两条最常被追问的性质,无缓冲 channel 为何是一次「会合」（rendezvous）、为何对它而言接收发生在发送完成之前（11.9），都会落到同一处机制上：直接传递（direct send / receive）。

收发的设计要同时满足三个约束。其一，正确：不能丢数据，不能让已关闭的 channel 吞下新值。其二，快：无竞争时一次收发应当只是「拿锁、拷一次、放锁」，热路径上连锁都尽量不碰。其三，公平：多个发送方或接收方阻塞在同一个 channel 上时，唤醒次序应当可预期（10.3.5）。下文先走通发送，再以对称的笔法带过接收，最后落到那处把二者统一起来的优化。

10.3.1 chansend 的三岔决策

编译器把 ch <- v 译成 chansend1，后者转调更通用的 chansend。chansend 的第三个参数 block 区分阻塞收发与 select 里的非阻塞分支（10.5）。剥去竞态检测、synctest 气泡与统计代码，它的主干是一道清晰的三岔决策：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


// chansend：向 channel 发送 ep 指向的值（裁剪后的速写）
func chansend(c *hchan, ep unsafe.Pointer, block bool) bool {
 if c == nil { // 向 nil channel 发送：永久阻塞
 if !block { return false }
 gopark(nil, nil, waitReasonChanSendNilChan, ...) // 不再返回
 throw("unreachable")
 }

 // 非阻塞快路径：不加锁就能判定的失败（详见 10.3.4）
 if !block && c.closed == 0 && full(c) {
 return false
 }

 lock(&c.lock)

 if c.closed != 0 { // 向已关闭 channel 发送：panic
 unlock(&c.lock)
 panic(plainError("send on closed channel"))
 }

 // 岔路一：recvq 里有等待的接收方 -> 直接传递，绕过 buf
 if sg := c.recvq.dequeue(); sg != nil {
 send(c, sg, ep, func() { unlock(&c.lock) })
 return true
 }

 // 岔路二：缓存还有空位 -> 把值拷进环形 buf
 if c.qcount < c.dataqsiz {
 qp := chanbuf(c, c.sendx)
 typedmemmove(c.elemtype, qp, ep) // 拷入 buf 的 sendx 槽
 c.sendx++
 if c.sendx == c.dataqsiz { c.sendx = 0 } // 环形回绕
 c.qcount++
 unlock(&c.lock)
 return true
 }

 // 岔路三：无接收方、buf 也满 -> 把自己挂进 sendq 并 park
 // ……见 10.3.3
}

三岔的优先级本身就是设计：有等待的接收方时，永远优先直接交给它，哪怕这是个带缓存且缓存里还有空位的 channel。直觉上似乎该「先填缓存」，但只要 recvq 非空，就说明缓存此刻必然为空（否则接收方早从缓存取走了，不会阻塞），于是绕过缓存直接交付不仅合法，还省下一次拷贝。这处优先级是下一节那个优化的前提。

10.4 关闭的语义

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

10.4 关闭的语义

前几节里，发送与接收都是「一对一」的会合：一次发送对上一次接收，多余的一方便阻塞等待。关闭是 channel 上唯一的「一对多」操作。close(ch) 由一个 Goroutine 发出，却能在一瞬间唤醒所有正阻塞在这条 channel 上的接收方，并让所有阻塞的发送方就地 panic。这种「一次广播、众人皆醒」的能力，使关闭从一个看似不起眼的清理动作，变成了 Go 并发里最常用的取消与收尾机制。done channel 模式、context 的取消（11.8），根子都在这里。

这一节回答三个问题：close 在运行时究竟做了什么，为什么它能成为广播原语；从一条已关闭的 channel 上接收会读到什么，for range 因何而终止；以及语言为关闭划下的三条 panic 红线，为什么它们宁可让程序当场崩溃，也不肯悄悄容错。

10.4.1 close 做了什么：一次加锁广播

关闭的实现集中在 runtime.closechan 一个函数里。它的骨架可以裁剪成三段:先在锁内置位 closed，再把 recvq 与 sendq 上所有等待者一次性摘下、装进一个本地链表，最后解锁、统一唤醒。下面是只保留设计要点的速写:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51


// closechan：关闭一条 channel（速写，去掉了竞态检测与 synctest 分支）
func closechan(c *hchan) {
 if c == nil {
 panic(plainError("close of nil channel")) // 红线一：close(nil)
 }

 lock(&c.lock)
 if c.closed != 0 {
 unlock(&c.lock)
 panic(plainError("close of closed channel")) // 红线二：重复关闭
 }
 c.closed = 1 // 置位，且不可逆

 var glist gList // 先收集，后唤醒：唤醒要在锁外做

 // 唤醒所有接收者：每个都将拿到零值，ok == false
 for {
 sg := c.recvq.dequeue()
 if sg == nil {
 break
 }
 if sg.elem != nil {
 typedmemclr(c.elemtype, sg.elem) // 把接收方的目标内存清零，即「零值」
 sg.elem = nil
 }
 gp := sg.g
 gp.param = unsafe.Pointer(sg)
 sg.success = false // 关键标志：本次接收并非来自一次真正的发送
 glist.push(gp)
 }

 // 唤醒所有发送者：它们醒来后会 panic
 for {
 sg := c.sendq.dequeue()
 if sg == nil {
 break
 }
 sg.elem = nil
 gp := sg.g
 gp.param = unsafe.Pointer(sg)
 sg.success = false
 glist.push(gp)
 }
 unlock(&c.lock)

 // 锁已释放，再把整张表逐一交还调度器
 for !glist.empty() {
 gp := glist.pop()
 goready(gp, 3)
 }
}

有三处设计值得点出。

10.5 select 的实现

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

10.5 select 的实现

前几节把单个 channel 的收发（10.3）讲清楚了。可现实里的 Goroutine 往往不只盯着一条 channel：它要在多个收发操作中，对先就绪的那个作出反应，还要能在「一个都没就绪」时不被阻塞。select 正是为此而生。它的语义看似简单，落到实现上却要同时解决两个棘手问题：多个就绪分支时如何公平地选一个，以及为执行一次 select 而锁住多条 channel 时如何不死锁。这两点决定了 selectgo 的全部结构，本节就围绕它们展开。

1
2
3
4
5
6
7
8


select {
case v := <-ch1: // ch1 可接收时执行
 use(v)
case ch2 <- x: // ch2 可发送时执行
 sent()
default: // 上面都未就绪时执行（可选）
 nonblocking()
}

约定先摆在前面。每个 case 描述一个 channel 操作（收或发），select 求值后至多执行一个 case 的通信。若有多个 case 同时就绪，从中等概率随机挑一个；若都未就绪，有 default 则执行 default（这使整条 select 变成非阻塞），无 default 则阻塞，直到某个 case 就绪。语言规范（Select statements）把这套语义钉死，运行时负责兑现，编译器负责把 source 形态翻译成运行时能消化的数据。

10.6 内存模型与无锁演进

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

10.6 内存模型与无锁演进

前几节把 channel 拆到了零件：10.3 的直接交付（direct handoff）让收发两端绕过环形缓冲直接传值，10.5 的 select 在多个就绪分支间做随机选择。这些机制解释了 channel「怎么跑」。本节回答两个更上层的问题：channel 给并发程序提供了什么可见性承诺，以及一个常被追问的工程疑案，channel 为什么至今仍是「一把锁加一个队列」，而不是传说中更快的无锁结构。前者把 channel 接回 11.9 的内存模型，后者则是一则关于「正确性与可维护性如何压过峰值性能」的真实取舍。

10.6.1 channel 的内存模型承诺

channel 不只是传数据的管子，它同时是建立 happens-before 的同步点。11.9 给出了 Go 内存模型的全貌，这里把其中与 channel 相关的四条规则单独拎出，逐条读懂它们的含义。 Go 内存模型（go.dev/ref/mem，2022 年 6 月版）对 channel 的规定如下，我们沿用 1.19 修订后的术语 synchronized before（同步先于，记作 $<$）：

一次发送同步先于对应接收的完成。对任意 channel（无论是否带缓冲）均成立。
close(ch) 同步先于一个因 channel 关闭而返回零值的接收。
对无缓冲 channel，一次接收同步先于对应发送的完成。
对容量为 $C$ 的缓冲 channel，第 $k$ 次接收同步先于第 $k+C$ 次发送的完成。

第 1 条是最朴素的直觉：把数据放进 channel 之前的所有写入，接收方在拿到这份数据之后都能看见。这正是「不要用共享内存来通信，而要用通信来共享内存」这句格言的形式化基础。一段最小的例子：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


var data int
var done = make(chan struct{})

func producer() {
	data = 42 // (1) 普通写
	close(done) // (2) 关闭即一次同步
}

func consumer() {
	<-done // (3) 接收完成
	print(data) // (4) 保证读到 42
}

(1) sequenced before (2)，由规则 2，(2) synchronized before (3)，(3) sequenced before (4)，三段拼接的传递闭包给出 (1) $<$ (4)，于是 (4) 必然读到 42。把这条链画出来，跨 goroutine 的那一步（close 同步先于接收）正是把两条程序序粘起来的关键边：

10.7 工程实践与跨语言对照

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

10.7 工程实践与跨语言对照

前面几节把 channel 的内部结构、收发路径与 select 的实现讲透了。读懂了机制，随之而来的是一个更难、也更工程的问题：什么时候该用 channel，什么时候不该用。 Go 的宣传语「Do not communicate by sharing memory; instead, share memory by communicating」容易被读成「凡共享状态皆应走 channel」，但这并非作者的本意。这一节把这句话还原成一条可操作的判别规则，对照同步原语章（第 11 章）里更轻的工具，再把 Go 的选择放进 CSP 家族的谱系里看，理解它在设计空间中的具体坐标。

10.7.1 channel 不是万能锤

2018 年 GopherCon 上，Go 团队的 Bryan C. Mills 做了一场题为「Rethinking Classical Concurrency Patterns」的演讲。他逐个检视了教科书里常见的并发范式，结论是：其中相当一部分若用 channel 实现，反而比用 sync 包里的原语更难写对、更慢。

第一个例子是「用 channel 模拟条件变量」。一个常见的写法是用一个带缓冲的 channel 当作「信号槽」，发送代表通知、接收代表等待：

1
2
3
4
5
6
7


// 反例：用 channel 当条件变量，看似优雅，边界全是坑
type Cond struct {
 ch chan struct{}
}

func (c *Cond) Wait() { <-c.ch }
func (c *Cond) Signal() { c.ch <- struct{}{} } // 没有等待者时会阻塞

它在「恰好一个等待者、恰好一个通知者」时能工作，可一旦等待者数目不定，问题就来了： Signal 在无人等待时会阻塞或丢失信号，Broadcast（唤醒全部等待者）无法表达，而条件谓词的重新检查（被唤醒后必须重新判断条件是否真的满足）也没有着落。正确的工具是 sync.Cond（11.4），它的 Wait 在唤醒后让调用者回到循环里复查谓词，Broadcast 一次唤醒所有等待者，这些语义 channel 都不天然具备。

第 10 章 通道与 select on Go 语言原本

10.1 通道与 CSP 的工程化

10.1 通道与 CSP 的工程化

10.1.1 把通信做成一等原语

10.2 hchan：通道的内部结构

10.2 hchan：通道的内部结构

10.2.1 三条不变式：先看「为什么」

10.2.2 hchan 的速写

10.3 收发与直接传递

10.3 收发与直接传递

10.3.1 chansend 的三岔决策

10.4 关闭的语义

10.4 关闭的语义

10.4.1 close 做了什么：一次加锁广播

10.5 select 的实现

10.5 select 的实现

10.6 内存模型与无锁演进

10.6 内存模型与无锁演进

10.6.1 channel 的内存模型承诺

10.7 工程实践与跨语言对照

10.7 工程实践与跨语言对照

10.7.1 channel 不是万能锤

第 10 章通道与 select on Go 语言原本