Bug - Tony Bai

本文永久链接 – https://tonybai.com/2025/11/20/proposal-improve-goroutine-stack-using-page-faults

大家好，我是Tony Bai。

Go 语言的 goroutine 以其轻量和高效著称，而其背后一个关键的“魔法”便是可动态增长的栈 (Resizable Stacks)。然而，支撑这个魔法的机制——在几乎每个函数入口处插入的“栈检查”指令——也并非毫无代价。

近日，在 golang-nuts 邮件组，一位名叫 Arseny Samoylov 的年轻开发者发起了一场引人深思的讨论，提出了一个颇具“革命性”的提案：我们能否借鉴 Linux 内核管理线程栈的方式，用“缺页中断”(Page Faults) 机制来取代 Go 现有的“栈检查”？

这个旨在挑战 Go 运行时基石的大胆设想，引来了 Go 语言联合创始人 Rob Pike 的亲自下场。本文中，我们就来简单看看这个看似优雅的提案，为何会引来社区的质疑，并最终被 Rob Pike 本人以“实现过于复杂”为由，泼上一盆“冷水”。

现状的“痛点”——无处不在的“栈检查”

在深入新提案之前，我们必须先理解 Go 当前的栈增长机制及其代价。

当前，Go 编译器会在几乎每一个非叶子函数的序言 (prologue) 部分，插入几条特殊的指令。这些指令的作用是在函数开始执行前，检查当前 goroutine 的剩余栈空间是否足够。如果不足，运行时 (runtime.morestack) 就会介入：分配一个更大的新栈，将旧栈的内容复制过去，调整所有指向栈上变量的指针，然后才继续执行函数。

提案者指出的当前机制的两大痛点：

CPU 开销：频繁的栈检查本身就是一种 CPU 开销，尤其是在调用链很深或存在大量无法内联的间接调用（如接口方法调用）时。
代码体积膨胀：每个函数都增加了额外的序言指令（提案者估计约 10 条指令），这会增加 L1 指令缓存 (L1i Cache) 的压力，对计算密集型任务的性能产生负面影响。

基于此，提案者估计，消除栈检查可能会为真实的 Go 应用带来 3% – 5% 的性能提升。

“革命”的设想——通过“缺页中断”实现栈增长

Arseny Samoylov 的提案，其灵感源自现代操作系统（如 Linux）管理原生线程栈的方式。

核心思想：

在创建一个 goroutine 时，不再只分配一个很小的物理内存（当前为 2KB），而是为其预留 (reserve) 一大块虚拟地址空间（例如 8MB），但不立即分配物理内存。
在这块虚拟地址空间的末尾，设置一个“警戒页”(Guard Page)，标记为不可访问。
移除编译器插入的所有“栈检查”指令。
当 goroutine 的栈增长，触及到未分配的内存页时，会触发一次缺页中断 (Page Fault)。操作系统内核会捕获这个中断，并“懒惰地”为其分配一页新的物理内存。
当 goroutine 的栈增长到极致，最终触及到那个“警戒页”时，Go 运行时捕获这个特定的信号，此时才执行现有的栈扩容逻辑。

这个设计的精妙之处在于，它将持续的、遍布每个函数的“栈检查”开销，转变成了仅在栈空间真正耗尽时才发生的一次性、代价较高的“异常处理”。

社区的讨论——一场关于性能、复杂性与可行性的权衡

这个看似优雅的方案，立刻引发了社区开发者的辩论。经验丰富的工程师们很快指出了这个方案背后隐藏的巨大挑战：

中断处理的巨大开销：Jason E. Aten 指出，处理一次缺页中断并由信号处理器接管，其过程极其缓慢。它涉及至少 4 次昂贵的上下文切换（用户态 -> 内核态 -> 信号处理器 -> 内核态 -> 用户态）。这个开销，可能远高于 Go 运行时目前高效的内存分配器。
区分“好”与“坏”的中断：Go 运行时如何能精确地区分出，一次缺页中断是因为“栈需要正常增长”，还是因为一个真正的 Bug（如 nil 指针解引用）？这是一个极其棘手的问题。
虚拟地址空间的消耗：虽然 64 位系统的虚拟地址空间极其巨大，但为每一个 goroutine 都预留 8MB，依然是一个不小的负担。10 万个 goroutine 将消耗 800GB 的虚拟地址空间。
最小栈的增加：最小的物理内存分配单位是一个页（通常是 4KB）。这意味着 goroutine 的最小栈大小将从 2KB 翻倍到 4KB，对于那些拥有数百万个小 goroutine 的应用，这可能会导致物理内存消耗翻倍。

Rob Pike 的“劝退”——来自创始人的最终裁决

当讨论进入白热化时，Go 语言的联合创始人 Rob Pike 亲自下场，给出了他的最终点评。他的观点，冷静而深刻，几乎为这场辩论画上了句号。

首先，他认为提案者夸大了“栈检查”的成本：

“我相信你夸大了（栈检查的）成本。它是可测量的，但并没有你说的那么严重。并且，随着函数内联越来越普遍，函数的体积变大，摊销后的实际成本都在降低。”

更重要的是，他指出了这个提案在工程上的历史困境，这正是“劝退”的核心理由：

“此外，在过去，使用内核traps 来实现栈增长一直都问题重重。我曾见过其他系统尝试这样做，但最终都因为无法预见的复杂性而放弃了。我不是说这做不到，但这绝非易事。而且，由于细节依赖于架构和操作系统，要做到可移植性非常困难。”

最后，他给出了一个简洁而有力的结论：

“这事不归我管，但我不会这么做。”
(It’s not up to me, but I wouldn’t do this.)

小结：永不停歇的探索，Go 演进的生命力

这场关于 goroutine 栈的“革命”提案，最终在创始人的“劝退”中似乎逐渐平息。然而，将此视为一次简单的“失败”，或许会错失其更深远的意义。

Rob Pike 的点评，以其数十年的工程经验和对复杂性的深刻洞察，为这个提案的技术路径亮起了警示的红灯。他指出的“无法预见的复杂性”和“难以解决的可移植性”，是任何试图修改语言运行时的工程师都必须敬畏的“冰山”。

然而，无论这位提案者 Arseny Samoylov 最终是选择接受劝告，还是不顾一切地继续探索并拿出概念验证 (PoC)，这场讨论本身，对 Go 社区而言，都是一件弥足珍贵的好事，它完美地体现了 Go 社区的生命力所在。

Go 语言的演进，正是在这种“大胆设想”与“审慎权衡”的持续张力中，稳步前行的。

资料链接：https://groups.google.com/g/golang-nuts/c/q3iZk0phN9E

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

告别低效，重塑开发范式
驾驭AI Agent(Claude Code)，实现工作流自动化
从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/11/10/rob-pike-on-complexity

大家好，我是Tony Bai。

在软件工程的殿堂里，我们常常将算法和数据结构奉为圭臬。我们痴迷于时间复杂度的优化，热衷于讨论各种精巧的数据结构。然而，Go 语言的联合创始人 Rob Pike 早在其1989年的一篇C 语言编程笔记中，就为我们留下了一份更根本的“忠告”。这份忠告，凝练为五条（或者说六条？）关于如何对抗软件“复杂性”的黄金法则。

这些法则，诞生于一个需要手动管理内存的时代，却惊人地预言并塑造了 Go 语言的设计哲学。它们的核心思想是：在构建真实世界的软件时，管理复杂性，远比追求算法上的极致精巧更为重要。

本文，就让我们以一名现代 Gopher 的视角，重新聆听这份来自创始人的忠告，理解为何这五条法则，才是构建健壮、可维护软件的真正基石。

法则一 & 二：停止猜测，开始测量

法则一：你无法预知程序的时间花销。

法则二：测量。在测量之前，不要进行性能调优。

这两条法则是所有性能工作的“第一性原理”。它们共同指向一个核心思想：你的直觉是不可靠的。

我们很容易陷入一个误区，认为性能瓶颈一定出在某个“看起来很慢”的算法上。然而，在现代计算机体系中，真正的瓶颈往往隐藏在意想不到的地方：一次意料之外的内存分配、一次糟糕的并发同步、或者一次灾难性的缓存未命中。

一个在“冷路径”上运行的、从 O(N) 优化到 O(1) 的完美算法，其对整体性能的贡献是零。而一个未经测量的、看似无害的“优化”，则可能因为破坏了缓存局部性或引入了锁竞争，反而让程序变得更慢。先找到正确的战场，远比拥有最锋利的武器更重要。

Go 语言将这两条法则的精神，内化为了其强大的工具链。在你动手将一个 O(N) 的循环优化成 O(log N) 之前，Go 的文化要求你：

使用 pprof 进行宏观分析：让数据告诉你，你的程序 90% 的时间到底花在了哪里。这份“忠告”要求我们，只对那个压倒性 (overwhelms) 的瓶颈进行优化。
使用 testing.B 进行微观验证：当你找到了瓶颈，并进行了一处“速度骇客” 般的优化后，用基准测试来证明你的修改确实带来了显著的提升。

法则三 & 四：简单胜于花哨

法则三：花哨的算法在 n 很小时很慢，而 n 通常很小。

法则四：花哨的算法比简单的算法更容易出错，也更难实现。

这两条法则是对“算法至上主义”的直接挑战。经典的算法复杂度（大O表示法）是一个强大的理论工具，但它在工程实践中具有欺骗性，因为它忽略了常数因子和实现的复杂性。

一个 O(log n) 的自平衡二叉树，其实现的复杂性、指针跳转带来的缓存不友好性，使得它在处理一个只有几百个元素的“日常问题”时，性能和健壮性可能远不如一个简单的、O(n) 的切片扫描。

在真实世界的软件中，可读性、可维护性和健壮性，是远比“理论上的最优性能”更为稀缺的资源。一个因过于复杂而充满 Bug 的“花哨”算法，其带来的危害，远大于一个简单、正确但“不够快”的算法。先做对，再做快——并且只有在测量证明有必要时才去做快。

Rob Pike的这两条法则简直就是 Go 语言的设计宣言！

切片 (slice) 和 map 就是一切：Go 刻意保持其内置数据结构的极度精简，正是因为在 99% 的场景下，它们简单、可预测且“足够好”。
“清晰胜于聪明 (Clear is better than clever)”：这是 Go 社区的集体共识。一段任何人都能在 3 秒钟内读懂的简单 for 循环，其长期维护价值，远高于一段只有作者本人才能看懂的、精巧但晦涩的代码。

法则五：数据为王

法则五：数据为王。如果你选对了数据结构并组织得当，算法几乎总是不言自明的。

这是所有法则中最具哲学高度的一条。它将我们的注意力，从“如何操作数据”（算法），拉回到了“如何组织数据”（数据结构）。

因为一个糟糕的数据结构，是任何精妙的算法都无法拯救的。它会迫使你编写出扭曲、晦涩、充满边界情况的“补丁式”代码。而一个优秀的数据结构，则会自然地引导你走向简单、清晰的算法。好的数据结构，是好算法的“母亲”。

这正是 Fred Brooks 在《人月神话》中思想的精髓：程序设计的核心，应该是对数据的思考和组织，而非对算法的炫技。

这也是 Go 语言面向组合、基于 struct 设计的灵魂所在。在 Go 中，我们花费最多时间思考的，往往是如何设计出清晰、正交的 struct。

一旦你的数据结构被设计得当，操作这些数据的方法自然就会变得简单、短小且不言自明。

// 优秀的设计：数据结构先行
type User struct {
    ID   int
    Name string
    Age  int
    Active bool
}

func (u *User) Deactivate() { ... }
func (u *User) IsMinor() bool { ... } // 是否未成年

当你拥有一个设计良好的 User 结构体时，Deactivate 或 IsMinor 这些方法的实现，几乎是“自证”的。

注：想想将Active换为 StatusFlag int ，Deactivate的实现还是“自证”的吗？

法则六：没有法则六

“Rule 6. There is no Rule 6.”

这句俏皮话，是 Rob Pike 编程哲学思想的点睛之笔。它以一种“元规则”的形式，深刻地诠释了前面所有法则的核心精神：对抗不必要的复杂性。它提醒我们，不要让规则本身成为一种新的复杂性来源。

小结

重温来自1989年 Rob Pike 的这份“忠告”，就像是回到了 Go 语言设计的“原点”。它们清晰地告诉我们，Go 语言的诞生，并非一次偶然的灵光一现，而是一种深思熟虑的、跨越数十年的编程哲学的最终体现。

在日常的 Go 开发中，我们或许会面临各种算法选择的诱惑。但 Rob Pike 的这些法则提醒我们，退后一步，首先去测量，去选择简单，去精心设计你的数据。这些看似朴素的原则，其重要性，往往超越了任何一个单一的、精巧的算法。因为它们所守护的，是软件项目中最宝贵的资产：长期的可维护性和清晰性。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？