背后的CSP：Go并发模型与Tony Hoare的传奇遗产)
很多 Go 项目里我最怕看到的不是复杂的算法而是一行简简单单的go func() { ... }()。不是说它危险——而是写下这行代码的人大部分时候并不清楚自己启动了什么东西。有人把它当开线程有人把它当异步任务还有人遇到并发 bug 才开始背 channel 和锁的口诀。这行语法其实承载着计算机科学里一段异常传奇的思想遗产。顺着它往上追你会碰到一位今年已 92 岁高龄的英国老先生Tony HoareC. A. R. Hoare。他在 1978 年写下的论文《Communicating Sequential Processes》通信顺序进程简称 CSP就是今天 Go 并发模型的直接理论源头。这篇论文前后有图灵奖、有快排、有被他自己称为十亿美元错误的空指针也有 Rob Pike 二十多年的语言实践。这篇文章想把go func()的运行时行为、CSP 的历史和生产里怎么设计并发这三件事串起来讲。看完之后你不但能说清楚 goroutine 和线程到底差在哪还能用 CSP 的视角重新审视自己写的每一处并发逻辑。1. 一行 go func() 背后运行时到底替你做了什么1.1 从开一个线程到登记一个协程写go func(){...}()的时候编译器不会原地调用这个函数而是把go语句降低成一个对运行时函数的调用把这个闭包连同参数一起交给 runtime。runtime 要做的是在堆上分配一个ggoroutine 对象初始化它的栈和状态把它标记为Grunnable塞进当前处理器P的本地运行队列然后立刻返回到你原来的代码。整个过程中没有系统调用没有内核对象没有 1MB 起步的线程栈。换句话说go func()并不是开线程而是登记一个协程。真正干活的MMachineOS 线程是复用的一批工人。你可能起了几千个 goroutine但实际占用的操作系统线程可能只有十几个。这就像公司里有一百个外包人员但工位只有八个。每次go func()你只是告诉前台等会儿有人来上工你看着安排。这个区别不是黑话而是性能的分水岭。创建一个线程的成本里包含了内核上下文切换、线程栈分配、调度器建块量级在几十微秒甚至更高而创建一个 goroutine 只需要在用户态分配一个小对象量级是亚微秒。所以 Go 社区敢说十万个 goroutine 起步没有哪个语言敢说十万个线程起步。1.2 2KB 的起始栈为什么 goroutine 能开到十万级别goroutine 的起始栈只有 2KB 左右按需增长64 位系统上最大能到 1GB。操作系统线程的栈通常是 1MB 到 8MB而且是静态分配的。一个线程 8MB一万个线程就是 80GB 内存这在绝大多数服务器上直接爆炸。goroutine 的栈是 分段栈 栈迁移 这套机制管理的。早期的实现是分段栈后来改成了连续栈拷贝当 2KB 不够用了runtime 在堆上分配一块更大的栈把旧栈内容整体拷过去然后修正所有栈指针。这个操作对用户透明但注意它意味着在栈上持有大量指向栈内对象的指针时栈拷贝的开销会被放大。有些热心人喜欢在每个 goroutine 的栈里塞个大切片结果性能反而难看。goroutine 阻塞也不是线程阻塞。当一个 goroutine 因为 channel 收发、锁、I/O 而停下来时runtime 会把 G 从 M 上摘下来标记为GwaitingM 立刻回去运行队列里拿下一个 G 继续跑。这一步是理解整个 Go 调度的钥匙阻塞一个 goroutine 几乎不浪费任何 OS 调度资源只是把一个 2KB 对象换个地方挂着。1.3 GMP 调度器和 channel 的隐藏联动GMP 模型不少人背过G 是 goroutineM 是机器/线程P 是处理器/调度上下文。GOMAXPROCS决定 P 的个数默认等于 CPU 逻辑核数。每个 P 有自己的本地运行队列全局还有一个共享队列用来兜底。M 没活干的时候会去偷其他 P 的 G这叫 work stealing。但很多文章把 GMP 讲成了任务分配器忽略了一个关键点channel 收发本身就是调度行为。举个例子你执行ch - x而ch是无缓冲 channel当前没有接收者。runtime 会把这个 goroutine 挂到这个 channel 的sendq队列里然后安排别的 G 运行。等到某个接收者出现了runtime 做的不是通知这两个 G 你们可以通信了而是直接把值从发送者的栈或寄存器传到接收者手里然后把发送者从等待队列里唤醒塞回运行队列。整个过程里channel 不是简单的队列 锁它是一整套和调度器深度耦合的通信协议。正是因为有这层机制Go 才能实现 CSP 的核心思想并发单元之间不靠共享变量协调靠通信协调。一个 goroutine 什么时候停、什么时候醒本质是由它和其他 goroutine 之间的通信关系决定的。这跟线程 锁的世界观完全不同——在那里阻塞和唤醒大多靠内核完成线程越多内核调度压力越大。2. 92 岁的老先生Tony Hoare 和 1978 年的 CSP2.1 从 ALGOL 编译器到图灵奖一个程序员的六十年Tony Hoare 的故事放在今天讲像某种爽文。他 1934 年出生在牛津读的是哲学、政治学和经济学的 PPE 专业后来又去莫斯科国立大学学过一段师从的概率论背景硬得吓人。1960 年他在英国 Elliott Brothers 实习任务是给 Elliott 503 计算机写 ALGOL 60 编译器。写编译器期间烦于排序效率顺手发明了快速排序——对就是你现在随手调用的sort.QuickSort。1969 年他又提出 Hoare Logic用形式化方法推理程序正确性。1974 年他和 Per Brinch Hansen 一起提出了 monitor管程概念这是当年解决操作系统并发问题的主流方案。注意这个细节monitor 的发明人之一也是他。monitor 是典型的共享状态 条件变量路线而后来他提出的 CSP 却走向了完全相反的方向——不共享状态只靠通信。亲手发明了 A 路线再亲手提出 B 路线最后 B 路线成了 Go 的底座。这种我全都要然后再否定自己的经历在计算机科学史上都罕见。1980 年他拿到图灵奖获奖演讲《The Emperors Old Clothes》讲的是 ALGOL 60 的历史教训。1999 年起他在微软剑桥研究院待了很多年。最著名的公众事件是 2009 年 QCon 上的坦白他在 1965 年设计 ALGOL W 时发明了 null 引用然后公开道歉说这玩意造成的损失可以用十亿美元计。一个 92 岁的老先生还在用极其坦诚的态度看待自己六十多年前的一个决定这种人生态度本身就很有说头。2.2 1978 年论文到底写了什么用今天的 Go 语法来翻译《Communicating Sequential Processes》发表在 1978 年的 CACM 上。它设想了一整套并发编程语法核心规则三条程序由若干顺序执行的进程组成进程之间不能共享变量通信必须通过具名通道同步进行一个进程要发数据另一个进程必须正好等着收。把当年的记号翻译成今天的 Go几乎可以画一张逐行对照表CSP1978Go今天含义进程 processgoroutine可独立调度的执行单元P ! e向进程 P 发送表达式 ech - e发送P ? v从进程 P 接收并赋给 vv : -ch接收a?x → F; b?y → G守卫式选择select { case x : -a: F; case y : -b: G }非确定性选择[P ∥ Q]并行组合go P(); go Q()并行执行有个细节需要厘清。Hoare 当时写的通道是按进程名通信的你想给进程 P 发东西就写P!e通道是进程的一个外部接口。Go 把通道提升成了第一类对象收发双方通过同一个 channel 值建立联系而不是通过进程名。这个改动看上去只是工程化实际上大大提升了灵活性——你可以在运行时传递 channel传入函数塞进结构体实现谁拿到通道谁就能通信的动态拓扑。CSP 是语法层面的设计Go 是运行时层面的实现这一点是两边真正分道扬镳的地方。但同步语义是完全继承的Go 的无缓冲 channel就是 CSP 的会合rendezvous概念。发送操作必须等到接收操作真正发生才完成反过来也一样。这个必须双方同时在场的设定是理解 channel 阻塞行为的根。2.3 论文之后的遗产Occam、transputer 与进程代数CSP 不是躺在纸面上的一篇论文。1983 年左右英国 INMOS 公司基于 CSP 设计了 Occam 语言并且专门做了一款叫 transputer 的微处理器把 channel 通信做进了芯片的硬件指令集里。Occam 的PAR和SEQ结构就是 CSP 并行组合和顺序组合的直接实现。今天很多并行计算的老工程师一看到 Go 的 goroutine channel第一反应都是这不就是 transputer 那套东西吗。1985 年Hoare 把论文扩展成同名的书《Communicating Sequential Processes》给出了完整的进程代数形式语义迹traces、失败failures、发散divergences。基于这套语义牛津大学后来做出了 FDR 模型检测器用来机械地验证 CSP 规范的属性。安全关键系统里CSP FDR 的组合用过很多年。所以在 Go 之前CSP 已经是经过验证的并行工程理论只是普通开发者接触不到。Go 做的贡献不是发明 CSP而是把这套理论从数学论文和特种硬件拉回了大众语言的 runtime 里。3. CSP 变成 Go一个人、三套语言和一个 2007 年的决定3.1 Rob Pike 的三十年 CSP 实践史把 CSP 从理论变成 Go最重要的人是 Rob Pike。他在贝尔实验室期间接连设计了三门语言1985 年前后的 Newsqueak1992 年的 Alef1995 年的 Limbo。这三门语言的时代背景不同——Newsqueak 偏图像脚本Alef 是 Plan 9 的系统编程语言Limbo 跑在 Inferno 操作系统上——但它们的并发模型同源进程 channel通信同步不用锁。到 2007 年Google 内部因为 C 构建时间太长、同时要处理海量并发服务开始设计一门新语言。设计者是 Robert Griesemer、Ken Thompson 和 Rob Pike。Pike 把 Newsqueak 以来二十年的 channel 经验直接带进了新语言的讨论。这解释了为什么 Go 的并发设计如此激进却又不显得生涩它不是一个 2007 年的灵光一现而是之前三代语言踩坑后的收敛结果。3.2 Go 对 CSP 的三处实用化改造严格讲Go 没有全盘照抄 CSP而是做了三处明显改造。第一处是缓冲 channel。CSP 的通信严格同步没有缓冲区概念。Go 的make(chan int, N)引入了容量 N发送方在缓冲区未满时不会阻塞这等于在纯通信模型里加入了解耦。好处是吞吐量上来了坏处是它经常掩盖同步错误——很多人用缓冲 channel 解决偶发阻塞的问题本质是把错误推迟而不是消掉等到缓冲满的时候照样炸。第二处是close和for range。CSP 里进程结束通信自然终止。Go 是长时间运行的服务语言需要一种显式的到此为止后面只有零值的信号。于是有了闭 channel 操作配合v, ok : -ch和for v : range ch。代价是引入了新规则向 closed channel 发送会 panic这个规则在后端代码里制造了不知多少凌晨两点的事故。第三处是 nil channel 的语义。对 nil channel 进行收发会永远阻塞这个看起来奇怪的设定在select里反而成了利器——把一个 case 的 channel 设为 nil就能不动声色地禁用它。跟这三处改造放在一起看Go 并不是CSP 的 Go 方言它是为服务端工程现实妥协过的 CSP。3.3 channel 的运行时结构通信也是调度如果你翻过 runtime 源码会看到 channel 的内部结构叫hchan。它里面有一块环形缓冲区bufsendx/recvx有两头等待队列sendq/recvq还有一个closed标志和一把锁。但别把它理解成普通消息队列关键是等待队列里的元素是sudog——它直接指向等待中的 goroutine。收发操作的核心逻辑是这样的发送时如果recvq里已有等待的接收者数据直接被交给第一个等待者不走缓冲区。否则如果缓冲区有空位数据进环形缓冲区。否则当前 goroutine 打包成sudog塞进sendq自身转入GwaitingM 去干别的。接收逻辑完全对称。这里最妙的是第一次收发发送者如果发现对面有人等直接把数据交出去压根不碰缓冲区。这叫直传在无缓冲 channel 上意味着一次同步通信可能完全没有内存拷贝只有 goroutine 状态迁移。《Go 内存模型》里对 channel 有两条关键保证无缓冲 channel 的发送 happens-before 接收完成有缓冲 channel 的发送 happens-before 对应的接收读取到该元素。这两条保证不是文档装饰而是你写并发代码时推理某个值是否可见的依据。channel 之所以能替代锁是因为它既是同步点又是内存屏障。4. 读懂源头之后生产代码可以这么写4.1 先记三条纪律再谈 APICSP 的核心是以通信为中心组织程序。落到 Go 日常开发里我给自己定了三条纪律每次 code review 都会检查。第一条能用 channel 表达的依赖关系不要用锁。两个 goroutine 之间如果只是把数据交给对方这就是通信关系天然用 channel。第二条每个 channel 都要有明确的 owner 和生命周期。谁创建、谁发送、谁接收、谁关闭必须在一段看得见的代码里写清楚。出现这个 channel 为什么还开着这段 goroutine 为什么不退出这类问题十有八九是 owner 没定好。第三条每个go func()都要有明确的退出路径。我 review 代码时不看功能先看 goroutine 有没有办法结束。没有退出路径的 goroutine 就像失联的卫星你以为它消失了它还在轨道上烧着内存。这三条不是谁规定的是 CSP 理论的一阶推论进程是基本单元进程必须能开始也必须能结束进程之间的关系由通信定义通信拓扑决定整个程序的生死。4.2 锁和 channel不是对立是分工Go 官方那句名言值得反复读Do not communicate by sharing memory; instead, share memory by communicating.——不要通过共享内存来通信要通过通信来共享内存。但别走极端。并发保护高频率小粒度的临界区比如维护一个计数器、保护一段短暂的不变量用sync.Mutex依然是对的channel 在场景里反而重了因为每次收发都涉及调度器联动。锁保护的是一段代码的状态一致性channel 连接的是两个执行单元的数据流。一个偏瞬时一个偏持续。真正该警惕的是用锁保护进程间依赖。比如 A 等 B 产生数据再处理用锁 条件变量写出来条件变量和 channel 在功能上等价但 channel 版本的意图清晰得多也少了很多边界分支。我见过太多sync.Cond代码最后全被 channel 改写。4.3 channel 所有权谁创建、谁负责关闭Go 团队在文档里给过一条硬规则不要在接收方关闭 channel如果 channel 有多个并发发送者也不要轻易关闭。原因很直接接收方不知道到底还要不要收多发送者中任何一个 close 都会毁掉其他发送者的合法写入。单发送者 单接收者/多接收者的场景最简单发送者close(ch)接收方用for range ch或v, ok : -ch判断结束。多发送者的场景就要靠通信协调关闭权比如用独立的 done channel所有发送者通过它得知退出另起一个协调者等全部发送者结束之后再 close 主 channel。很多人问我多发送者到底怎么关 channel答案通常是先想清楚谁有权利代表所有发送者宣布结束这个角色才是真正的关闭者。一个容易忽略的细节接收 closed channel 会立刻返回零值如果你在select里挂着已关闭的 channel它会一直就绪导致死循环。这时候可以把该 channel 置为 nilselect 的这条 case 就自然失效了。这是 nil channel 语义在生产里的高级用法很老练但文档外很难查到。4.4 一个生产级 worker pool 模板理解了所有权和退出路径最直观的练手场景就是 worker pool。下面这份代码经我维护过很多版本直接抄也行func workerPool(jobs -chan int, results chan- int, numWorkers int, wg *sync.WaitGroup) { for i : 0; i numWorkers; i { wg.Add(1) go func(id int) { defer wg.Done() for job : range jobs { results - process(job) } }(i) } } func process(job int) int { // 模拟耗时任务 return job * 2 } func main() { const numJobs 100 const numWorkers 4 jobs : make(chan int, numJobs) results : make(chan int, numJobs) var wg sync.WaitGroup workerPool(jobs, results, numWorkers, wg) for j : 1; j numJobs; j { jobs - j } close(jobs) go func() { wg.Wait() close(results) }() for r : range results { _ r // 消费结果 } }注意我把results的容量也开成了numJobs。在小任务量下这是最简单的写法如果任务量大这样会多占内存更讲究的做法是让主流程边投任务边消费结果或者把结果消费放进独立 goroutine。worker 从jobs里range天然处理了 channel 关闭后的退出问题results由wg.Wait()之后的 goroutine 负责关闭保证所有写入者都结束后才关这就是所有权纪律的落地。4.5 select 的公平性、超时与取消select是 CSP 守卫式命令的 Go 形态。Go 1.14 之后select 在所有就绪分支之间做均匀随机选择避免某个 channel 一直被饿着。这个改动之前某个 case 总是先到导致的非公平现象是真真实实出现过的。超时和取消是生产代码每天都在用的事。基础写法是ctx, cancel : context.WithTimeout(context.Background(), 2*time.Second) defer cancel() select { case res : -result: handleRes(res) case -ctx.Done(): log.Println(timeout or canceled:, ctx.Err()) }再补一个容易踩的点time.After在 select 里用得很顺手但如果 select 是循环执行的每次进来都会创建一个新的计时器直到它到点之后才释放。频繁触发循环时这是一个隐形的资源泄漏。context.WithTimeout搭配defer cancel()能规避这种泄漏。别问我是怎么知道的凌晨的 on-call 群里什么都见过。5. 写在最后一行 go func() 里的工程史说实话我最早写 Go 的时候也是背语法的状态。直到有一次排查线上 goroutine 泄漏服务的 goroutine 数直接干到几十万dump 出来一水儿的go func() { ... }()才意识到自己从未真正理解这行代码意味着什么。后来去翻 CSP 论文去读 Newsqueak 的资料再回头看go func()观感完全变了。Tony Hoare 1978 年写论文时 44 岁如今 92 岁。他当年用数学语言描述的同步通信进程今天跑在你我的线上服务里。从论文到 Occam 再到 transputer从 Newsqueak 到 Alef 再到 Limbo最后在 2007 年汇入 Go——这行语法后面站着的不是某个工程师的天才而是一条跨越四十年的理论验证链。我自己现在的习惯很朴素每次 code review只要看到go func()就一定会追问三件事——这个 goroutine 怎么结束它和外界之间靠哪些 channel 或者 context 通信谁负责关闭通道如果这三件事都不能一句话答清那段代码再漂亮我也不会合入。这就是 CSP 留给我的最大遗产并发不是起任务的技术是定义关系与边界的技术。每次敲下go func()时想想那个 92 岁的老先生想想你要把哪段通信拓扑交给 runtime——想明白了你的并发代码自然会简单下来。 
长河君 · 2026/9/28 9:14:27 · 阅读 1.2k go func()背后的CSP：Go并发模型与Tony Hoare的传奇遗产
很多 Go 项目里我最怕看到的不是复杂的算法而是一行简简单单的go func() { ... }()。不是说它危险——而是写下这行代码的人大部分时候并不清楚自己启动了什么东西。有人把它当开线程有人把它当异步任务还有人遇到并发 bug 才开始背 channel 和锁的口诀。这行语法其实承载着计算机科学里一段异常传奇的思想遗产。顺着它往上追你会碰到一位今年已 92 岁高龄的英国老先生Tony HoareC. A. R. Hoare。他在 1978 年写下的论文《Communicating Sequential Processes》通信顺序进程简称 CSP就是今天 Go 并发模型的直接理论源头。这篇论文前后有图灵奖、有快排、有被他自己称为十亿美元错误的空指针也有 Rob Pike 二十多年的语言实践。这篇文章想把go func()的运行时行为、CSP 的历史和生产里怎么设计并发这三件事串起来讲。看完之后你不但能说清楚 goroutine 和线程到底差在哪还能用 CSP 的视角重新审视自己写的每一处并发逻辑。1. 一行 go func() 背后运行时到底替你做了什么1.1 从开一个线程到登记一个协程写go func(){...}()的时候编译器不会原地调用这个函数而是把go语句降低成一个对运行时函数的调用把这个闭包连同参数一起交给 runtime。runtime 要做的是在堆上分配一个ggoroutine 对象初始化它的栈和状态把它标记为Grunnable塞进当前处理器P的本地运行队列然后立刻返回到你原来的代码。整个过程中没有系统调用没有内核对象没有 1MB 起步的线程栈。换句话说go func()并不是开线程而是登记一个协程。真正干活的MMachineOS 线程是复用的一批工人。你可能起了几千个 goroutine但实际占用的操作系统线程可能只有十几个。这就像公司里有一百个外包人员但工位只有八个。每次go func()你只是告诉前台等会儿有人来上工你看着安排。这个区别不是黑话而是性能的分水岭。创建一个线程的成本里包含了内核上下文切换、线程栈分配、调度器建块量级在几十微秒甚至更高而创建一个 goroutine 只需要在用户态分配一个小对象量级是亚微秒。所以 Go 社区敢说十万个 goroutine 起步没有哪个语言敢说十万个线程起步。1.2 2KB 的起始栈为什么 goroutine 能开到十万级别goroutine 的起始栈只有 2KB 左右按需增长64 位系统上最大能到 1GB。操作系统线程的栈通常是 1MB 到 8MB而且是静态分配的。一个线程 8MB一万个线程就是 80GB 内存这在绝大多数服务器上直接爆炸。goroutine 的栈是 分段栈 栈迁移 这套机制管理的。早期的实现是分段栈后来改成了连续栈拷贝当 2KB 不够用了runtime 在堆上分配一块更大的栈把旧栈内容整体拷过去然后修正所有栈指针。这个操作对用户透明但注意它意味着在栈上持有大量指向栈内对象的指针时栈拷贝的开销会被放大。有些热心人喜欢在每个 goroutine 的栈里塞个大切片结果性能反而难看。goroutine 阻塞也不是线程阻塞。当一个 goroutine 因为 channel 收发、锁、I/O 而停下来时runtime 会把 G 从 M 上摘下来标记为GwaitingM 立刻回去运行队列里拿下一个 G 继续跑。这一步是理解整个 Go 调度的钥匙阻塞一个 goroutine 几乎不浪费任何 OS 调度资源只是把一个 2KB 对象换个地方挂着。1.3 GMP 调度器和 channel 的隐藏联动GMP 模型不少人背过G 是 goroutineM 是机器/线程P 是处理器/调度上下文。GOMAXPROCS决定 P 的个数默认等于 CPU 逻辑核数。每个 P 有自己的本地运行队列全局还有一个共享队列用来兜底。M 没活干的时候会去偷其他 P 的 G这叫 work stealing。但很多文章把 GMP 讲成了任务分配器忽略了一个关键点channel 收发本身就是调度行为。举个例子你执行ch - x而ch是无缓冲 channel当前没有接收者。runtime 会把这个 goroutine 挂到这个 channel 的sendq队列里然后安排别的 G 运行。等到某个接收者出现了runtime 做的不是通知这两个 G 你们可以通信了而是直接把值从发送者的栈或寄存器传到接收者手里然后把发送者从等待队列里唤醒塞回运行队列。整个过程里channel 不是简单的队列 锁它是一整套和调度器深度耦合的通信协议。正是因为有这层机制Go 才能实现 CSP 的核心思想并发单元之间不靠共享变量协调靠通信协调。一个 goroutine 什么时候停、什么时候醒本质是由它和其他 goroutine 之间的通信关系决定的。这跟线程 锁的世界观完全不同——在那里阻塞和唤醒大多靠内核完成线程越多内核调度压力越大。2. 92 岁的老先生Tony Hoare 和 1978 年的 CSP2.1 从 ALGOL 编译器到图灵奖一个程序员的六十年Tony Hoare 的故事放在今天讲像某种爽文。他 1934 年出生在牛津读的是哲学、政治学和经济学的 PPE 专业后来又去莫斯科国立大学学过一段师从的概率论背景硬得吓人。1960 年他在英国 Elliott Brothers 实习任务是给 Elliott 503 计算机写 ALGOL 60 编译器。写编译器期间烦于排序效率顺手发明了快速排序——对就是你现在随手调用的sort.QuickSort。1969 年他又提出 Hoare Logic用形式化方法推理程序正确性。1974 年他和 Per Brinch Hansen 一起提出了 monitor管程概念这是当年解决操作系统并发问题的主流方案。注意这个细节monitor 的发明人之一也是他。monitor 是典型的共享状态 条件变量路线而后来他提出的 CSP 却走向了完全相反的方向——不共享状态只靠通信。亲手发明了 A 路线再亲手提出 B 路线最后 B 路线成了 Go 的底座。这种我全都要然后再否定自己的经历在计算机科学史上都罕见。1980 年他拿到图灵奖获奖演讲《The Emperors Old Clothes》讲的是 ALGOL 60 的历史教训。1999 年起他在微软剑桥研究院待了很多年。最著名的公众事件是 2009 年 QCon 上的坦白他在 1965 年设计 ALGOL W 时发明了 null 引用然后公开道歉说这玩意造成的损失可以用十亿美元计。一个 92 岁的老先生还在用极其坦诚的态度看待自己六十多年前的一个决定这种人生态度本身就很有说头。2.2 1978 年论文到底写了什么用今天的 Go 语法来翻译《Communicating Sequential Processes》发表在 1978 年的 CACM 上。它设想了一整套并发编程语法核心规则三条程序由若干顺序执行的进程组成进程之间不能共享变量通信必须通过具名通道同步进行一个进程要发数据另一个进程必须正好等着收。把当年的记号翻译成今天的 Go几乎可以画一张逐行对照表CSP1978Go今天含义进程 processgoroutine可独立调度的执行单元P ! e向进程 P 发送表达式 ech - e发送P ? v从进程 P 接收并赋给 vv : -ch接收a?x → F; b?y → G守卫式选择select { case x : -a: F; case y : -b: G }非确定性选择[P ∥ Q]并行组合go P(); go Q()并行执行有个细节需要厘清。Hoare 当时写的通道是按进程名通信的你想给进程 P 发东西就写P!e通道是进程的一个外部接口。Go 把通道提升成了第一类对象收发双方通过同一个 channel 值建立联系而不是通过进程名。这个改动看上去只是工程化实际上大大提升了灵活性——你可以在运行时传递 channel传入函数塞进结构体实现谁拿到通道谁就能通信的动态拓扑。CSP 是语法层面的设计Go 是运行时层面的实现这一点是两边真正分道扬镳的地方。但同步语义是完全继承的Go 的无缓冲 channel就是 CSP 的会合rendezvous概念。发送操作必须等到接收操作真正发生才完成反过来也一样。这个必须双方同时在场的设定是理解 channel 阻塞行为的根。2.3 论文之后的遗产Occam、transputer 与进程代数CSP 不是躺在纸面上的一篇论文。1983 年左右英国 INMOS 公司基于 CSP 设计了 Occam 语言并且专门做了一款叫 transputer 的微处理器把 channel 通信做进了芯片的硬件指令集里。Occam 的PAR和SEQ结构就是 CSP 并行组合和顺序组合的直接实现。今天很多并行计算的老工程师一看到 Go 的 goroutine channel第一反应都是这不就是 transputer 那套东西吗。1985 年Hoare 把论文扩展成同名的书《Communicating Sequential Processes》给出了完整的进程代数形式语义迹traces、失败failures、发散divergences。基于这套语义牛津大学后来做出了 FDR 模型检测器用来机械地验证 CSP 规范的属性。安全关键系统里CSP FDR 的组合用过很多年。所以在 Go 之前CSP 已经是经过验证的并行工程理论只是普通开发者接触不到。Go 做的贡献不是发明 CSP而是把这套理论从数学论文和特种硬件拉回了大众语言的 runtime 里。3. CSP 变成 Go一个人、三套语言和一个 2007 年的决定3.1 Rob Pike 的三十年 CSP 实践史把 CSP 从理论变成 Go最重要的人是 Rob Pike。他在贝尔实验室期间接连设计了三门语言1985 年前后的 Newsqueak1992 年的 Alef1995 年的 Limbo。这三门语言的时代背景不同——Newsqueak 偏图像脚本Alef 是 Plan 9 的系统编程语言Limbo 跑在 Inferno 操作系统上——但它们的并发模型同源进程 channel通信同步不用锁。到 2007 年Google 内部因为 C 构建时间太长、同时要处理海量并发服务开始设计一门新语言。设计者是 Robert Griesemer、Ken Thompson 和 Rob Pike。Pike 把 Newsqueak 以来二十年的 channel 经验直接带进了新语言的讨论。这解释了为什么 Go 的并发设计如此激进却又不显得生涩它不是一个 2007 年的灵光一现而是之前三代语言踩坑后的收敛结果。3.2 Go 对 CSP 的三处实用化改造严格讲Go 没有全盘照抄 CSP而是做了三处明显改造。第一处是缓冲 channel。CSP 的通信严格同步没有缓冲区概念。Go 的make(chan int, N)引入了容量 N发送方在缓冲区未满时不会阻塞这等于在纯通信模型里加入了解耦。好处是吞吐量上来了坏处是它经常掩盖同步错误——很多人用缓冲 channel 解决偶发阻塞的问题本质是把错误推迟而不是消掉等到缓冲满的时候照样炸。第二处是close和for range。CSP 里进程结束通信自然终止。Go 是长时间运行的服务语言需要一种显式的到此为止后面只有零值的信号。于是有了闭 channel 操作配合v, ok : -ch和for v : range ch。代价是引入了新规则向 closed channel 发送会 panic这个规则在后端代码里制造了不知多少凌晨两点的事故。第三处是 nil channel 的语义。对 nil channel 进行收发会永远阻塞这个看起来奇怪的设定在select里反而成了利器——把一个 case 的 channel 设为 nil就能不动声色地禁用它。跟这三处改造放在一起看Go 并不是CSP 的 Go 方言它是为服务端工程现实妥协过的 CSP。3.3 channel 的运行时结构通信也是调度如果你翻过 runtime 源码会看到 channel 的内部结构叫hchan。它里面有一块环形缓冲区bufsendx/recvx有两头等待队列sendq/recvq还有一个closed标志和一把锁。但别把它理解成普通消息队列关键是等待队列里的元素是sudog——它直接指向等待中的 goroutine。收发操作的核心逻辑是这样的发送时如果recvq里已有等待的接收者数据直接被交给第一个等待者不走缓冲区。否则如果缓冲区有空位数据进环形缓冲区。否则当前 goroutine 打包成sudog塞进sendq自身转入GwaitingM 去干别的。接收逻辑完全对称。这里最妙的是第一次收发发送者如果发现对面有人等直接把数据交出去压根不碰缓冲区。这叫直传在无缓冲 channel 上意味着一次同步通信可能完全没有内存拷贝只有 goroutine 状态迁移。《Go 内存模型》里对 channel 有两条关键保证无缓冲 channel 的发送 happens-before 接收完成有缓冲 channel 的发送 happens-before 对应的接收读取到该元素。这两条保证不是文档装饰而是你写并发代码时推理某个值是否可见的依据。channel 之所以能替代锁是因为它既是同步点又是内存屏障。4. 读懂源头之后生产代码可以这么写4.1 先记三条纪律再谈 APICSP 的核心是以通信为中心组织程序。落到 Go 日常开发里我给自己定了三条纪律每次 code review 都会检查。第一条能用 channel 表达的依赖关系不要用锁。两个 goroutine 之间如果只是把数据交给对方这就是通信关系天然用 channel。第二条每个 channel 都要有明确的 owner 和生命周期。谁创建、谁发送、谁接收、谁关闭必须在一段看得见的代码里写清楚。出现这个 channel 为什么还开着这段 goroutine 为什么不退出这类问题十有八九是 owner 没定好。第三条每个go func()都要有明确的退出路径。我 review 代码时不看功能先看 goroutine 有没有办法结束。没有退出路径的 goroutine 就像失联的卫星你以为它消失了它还在轨道上烧着内存。这三条不是谁规定的是 CSP 理论的一阶推论进程是基本单元进程必须能开始也必须能结束进程之间的关系由通信定义通信拓扑决定整个程序的生死。4.2 锁和 channel不是对立是分工Go 官方那句名言值得反复读Do not communicate by sharing memory; instead, share memory by communicating.——不要通过共享内存来通信要通过通信来共享内存。但别走极端。并发保护高频率小粒度的临界区比如维护一个计数器、保护一段短暂的不变量用sync.Mutex依然是对的channel 在场景里反而重了因为每次收发都涉及调度器联动。锁保护的是一段代码的状态一致性channel 连接的是两个执行单元的数据流。一个偏瞬时一个偏持续。真正该警惕的是用锁保护进程间依赖。比如 A 等 B 产生数据再处理用锁 条件变量写出来条件变量和 channel 在功能上等价但 channel 版本的意图清晰得多也少了很多边界分支。我见过太多sync.Cond代码最后全被 channel 改写。4.3 channel 所有权谁创建、谁负责关闭Go 团队在文档里给过一条硬规则不要在接收方关闭 channel如果 channel 有多个并发发送者也不要轻易关闭。原因很直接接收方不知道到底还要不要收多发送者中任何一个 close 都会毁掉其他发送者的合法写入。单发送者 单接收者/多接收者的场景最简单发送者close(ch)接收方用for range ch或v, ok : -ch判断结束。多发送者的场景就要靠通信协调关闭权比如用独立的 done channel所有发送者通过它得知退出另起一个协调者等全部发送者结束之后再 close 主 channel。很多人问我多发送者到底怎么关 channel答案通常是先想清楚谁有权利代表所有发送者宣布结束这个角色才是真正的关闭者。一个容易忽略的细节接收 closed channel 会立刻返回零值如果你在select里挂着已关闭的 channel它会一直就绪导致死循环。这时候可以把该 channel 置为 nilselect 的这条 case 就自然失效了。这是 nil channel 语义在生产里的高级用法很老练但文档外很难查到。4.4 一个生产级 worker pool 模板理解了所有权和退出路径最直观的练手场景就是 worker pool。下面这份代码经我维护过很多版本直接抄也行func workerPool(jobs -chan int, results chan- int, numWorkers int, wg *sync.WaitGroup) { for i : 0; i numWorkers; i { wg.Add(1) go func(id int) { defer wg.Done() for job : range jobs { results - process(job) } }(i) } } func process(job int) int { // 模拟耗时任务 return job * 2 } func main() { const numJobs 100 const numWorkers 4 jobs : make(chan int, numJobs) results : make(chan int, numJobs) var wg sync.WaitGroup workerPool(jobs, results, numWorkers, wg) for j : 1; j numJobs; j { jobs - j } close(jobs) go func() { wg.Wait() close(results) }() for r : range results { _ r // 消费结果 } }注意我把results的容量也开成了numJobs。在小任务量下这是最简单的写法如果任务量大这样会多占内存更讲究的做法是让主流程边投任务边消费结果或者把结果消费放进独立 goroutine。worker 从jobs里range天然处理了 channel 关闭后的退出问题results由wg.Wait()之后的 goroutine 负责关闭保证所有写入者都结束后才关这就是所有权纪律的落地。4.5 select 的公平性、超时与取消select是 CSP 守卫式命令的 Go 形态。Go 1.14 之后select 在所有就绪分支之间做均匀随机选择避免某个 channel 一直被饿着。这个改动之前某个 case 总是先到导致的非公平现象是真真实实出现过的。超时和取消是生产代码每天都在用的事。基础写法是ctx, cancel : context.WithTimeout(context.Background(), 2*time.Second) defer cancel() select { case res : -result: handleRes(res) case -ctx.Done(): log.Println(timeout or canceled:, ctx.Err()) }再补一个容易踩的点time.After在 select 里用得很顺手但如果 select 是循环执行的每次进来都会创建一个新的计时器直到它到点之后才释放。频繁触发循环时这是一个隐形的资源泄漏。context.WithTimeout搭配defer cancel()能规避这种泄漏。别问我是怎么知道的凌晨的 on-call 群里什么都见过。5. 写在最后一行 go func() 里的工程史说实话我最早写 Go 的时候也是背语法的状态。直到有一次排查线上 goroutine 泄漏服务的 goroutine 数直接干到几十万dump 出来一水儿的go func() { ... }()才意识到自己从未真正理解这行代码意味着什么。后来去翻 CSP 论文去读 Newsqueak 的资料再回头看go func()观感完全变了。Tony Hoare 1978 年写论文时 44 岁如今 92 岁。他当年用数学语言描述的同步通信进程今天跑在你我的线上服务里。从论文到 Occam 再到 transputer从 Newsqueak 到 Alef 再到 Limbo最后在 2007 年汇入 Go——这行语法后面站着的不是某个工程师的天才而是一条跨越四十年的理论验证链。我自己现在的习惯很朴素每次 code review只要看到go func()就一定会追问三件事——这个 goroutine 怎么结束它和外界之间靠哪些 channel 或者 context 通信谁负责关闭通道如果这三件事都不能一句话答清那段代码再漂亮我也不会合入。这就是 CSP 留给我的最大遗产并发不是起任务的技术是定义关系与边界的技术。每次敲下go func()时想想那个 92 岁的老先生想想你要把哪段通信拓扑交给 runtime——想明白了你的并发代码自然会简单下来。