本文永久链接 – 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) 就会介入：分配一个更大的新栈，将旧栈的内容复制过去，调整所有指向栈上变量的指针，然后才继续执行函数。

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

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

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

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

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

核心思想：

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

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

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

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

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

大家好，我是Tony Bai。

今年的 Go 官方16岁“庆生”文章，来得比以往时候都要晚一些。

往年，我们总能在 11 月 10 日或 11 日，准时收到这份来自 Go 团队的年度“家庭来信”。但今年，日历翻过了好几天，官方博客却依旧静悄悄。前几天，我还在知识星球上和星友们“抱怨”：“今年 Go 官方居然没有发 16 周年庆生纪念文章，比较反常啊！是忙忘了？还是没人有空写？”

现在回头看，这份“迟到”的生日礼物，或许恰恰反映了 Go 团队当前的状态。与其说是“忙忘了”，我更倾向于相信，这是新任技术负责人 Austin Clements 那种众所周知的严谨风格的体现——在没有将过去一年的所有重要进展都梳理清晰、打磨完美之前，宁愿延迟，也绝不仓促发文。抑或是，随着 Go 在 AI 时代的责任日益重大，团队的每一个字，都变得更加审慎和深思熟虑。

那么，这份姗姗来迟的“年度报告”，又为何值得我们全文翻译，并分享给大家呢？

因为这不仅仅是一篇生日贺文，它更是一份极其珍贵的、信息密度极高的官方“战略简报”。

在这篇文章里，Go 团队不仅系统性地盘点了过去一年中，从核心语言、安全体系到工具链的所有重大成果（synctest, Green Tea GC, FIPS 认证, go fix…），更重要的是，它首次清晰地、成体系地阐述了 Go 在 AI 时代的定位与雄心。它告诉我们，Go 团队正在如何将 Go 语言独特的并发、性能和可靠性优势，注入到 AI 集成、Agent 和基础设施的构建中。

对于我们每一位 Gopher 而言，这篇文章就是一张官方的“藏宝图”。它不仅能帮助我们快速跟上 Go 的最新动态，更能让我们洞察这门语言未来的发展方向，从而在技术浪潮中，做出更明智的学习和职业决策。

下面，就让我们一同深入这份迟到但分量十足的“生日礼物”。以下是文章全文。

刚刚过去的周一，11 月 10 日，我们庆祝了 Go 开源发布 16 周年！

我们遵循了现在已经非常成熟和可靠的发布节奏，在二月份发布了 Go 1.24，并在八月份发布了 Go 1.25。为了继续我们构建最高效的生产系统语言平台的使命，这些版本包含了用于构建健壮可靠软件的新 API，在 Go 构建安全软件的记录上取得了显著进展，以及一些重要的底层改进。与此同时，没有人能忽视生成式 AI 给我们行业带来的巨大变革。Go 团队正以深思熟虑且毫不妥协的思维方式应对这一充满活力的领域中的挑战和机遇，致力于将 Go 的生产就绪方法应用于构建健壮的 AI 集成、产品、智能体和基础设施。

核心语言和库的改进

新的 testing/synctest 包在 Go 1.24 中作为实验性功能首次发布，然后在 Go 1.25 中正式毕业，它极大地简化了为并发、异步代码编写测试的过程。这类代码在网络服务中尤为常见，并且传统上很难进行良好的测试。synctest 包通过虚拟化时间本身来工作。它将过去缓慢、不稳定或两者兼有的测试，转变为易于重写成可靠且几乎瞬时完成的测试，通常只需增加几行代码。这也是 Go 软件开发集成方法的一个绝佳例子：在一个几乎微不足道的 API 背后，synctest 包隐藏了与 Go 运行时和标准库其他部分的深度集成。

这并非过去一年中 testing 包得到的唯一增强。新的 testing.B.Loop API 不仅比原来的 testing.B.N API 更易于使用，还解决了编写 Go 基准测试时许多传统的——且常常是不可见的！——陷阱。testing 包还新增了 API，可以轻松地在使用 Context 的测试中进行清理，以及轻松地向测试日志写入内容。

Go 和容器化技术一同成长，并彼此配合得很好。Go 1.25 推出了容器感知调度，使这对组合更加强大。开发者无需任何操作，它就能透明地调整在容器中运行的 Go 工作负载的并行度，防止可能影响尾部延迟的 CPU 节流，并提升了 Go 开箱即用的生产就绪性。

Go 1.25 的新飞行记录器(flight recorder)建立在我们本已强大的执行追踪器之上，能够深入洞察生产系统的动态行为。执行追踪器通常会收集过多的信息，在长期运行的生产服务中不太实用，而飞行记录器则像一个小小的时光机，允许服务在出现问题之后，以极高的细节快照最近发生的事件。

安全软件开发

Go 继续加强其对安全软件开发的承诺，在其原生加密包方面取得了重大进展，并演进其标准库以增强安全性。

Go 在标准库中附带了一整套原生加密包，这些包在过去一年中达到了两个重要的里程碑。由独立安全公司 Trail of Bits 进行的安全审计取得了优异的结果，仅有一个低严重性的发现。此外，通过 Go 安全团队与 Geomys 的合作，这些包获得了 CAVP 认证，为完整的 FIPS 140-3 认证铺平了道路。这对于在某些受监管环境中的 Go 用户来说是一项至关重要的进展。FIPS 140 合规性，以往由于需要使用不受支持的解决方案而成为一个摩擦点，现在将被无缝集成，解决了与安全性、开发者体验、功能性、发布速度和合规性相关的问题。

Go 标准库持续演进，以实现默认安全和设计安全。例如，Go 1.24 中添加的 os.Root API 实现了抗遍历的文件系统访问，有效地对抗了一类漏洞，即攻击者可能操纵程序访问本应不可访问的文件。这类漏洞在没有底层平台和操作系统支持的情况下极具挑战性，而新的 os.Root API 提供了一个直接、一致且可移植的解决方案。

底层改进

除了用户可见的更改，Go 在过去一年中还在底层做了重大改进。

在 Go 1.24 中，我们完全重新设计了 map 的实现，借鉴了哈希表设计中最新、最伟大的思想。这一更改是完全透明的，并为 map 的性能带来了显著提升，降低了 map 操作的尾部延迟，在某些情况下甚至带来了显著的内存节省。

Go 1.25 包含了一个实验性的、在 Go 垃圾回收器方面的重大进步，名为 Green Tea。Green Tea 在许多应用程序中将垃圾回收开销减少了至少 10%，有时甚至高达 40%。它使用了一种专为当今硬件的能力和限制而设计的新颖算法，并开辟了一个我们正热切探索的新设计空间。例如，在即将发布的 Go 1.26 版本中，Green Tea 将在支持 AVX-512 向量指令的硬件上额外实现 10% 的垃圾回收器开销降低——这在旧算法中几乎是不可能的。Green Tea 将在 Go 1.26 中默认启用；用户只需升级他们的 Go 版本即可受益。

进一步发展软件开发栈

Go 远不止于语言和标准库。它是一个软件开发平台，在过去一年里，我们还对 gopls 语言服务器进行了四次常规发布，并建立了合作伙伴关系以支持新兴的智能体应用程序新框架。

Gopls 为 VS Code 和其他基于 LSP 的编辑器和 IDE 提供 Go 支持。每个版本都有一系列的功能和改进，提升了阅读和编写 Go 代码的体验（详情请见 v0.17.0、v0.18.0、v0.19.0 和 v0.20.0 的发布说明，或我们新的 gopls 功能文档！）。一些亮点包括：许多新增和增强的分析器，帮助开发者编写更地道和健壮的 Go 代码；对变量提取、变量内联和 JSON 结构体标签的重构支持；以及一个实验性的内置MCP服务器，用于模型上下文协议（MCP），它以 MCP 工具的形式向 AI 助手暴露了 gopls 的一部分功能。

从 gopls v0.18.0 开始，我们开始探索自动代码现代化工具。随着 Go 的演进，每个版本都带来了新的能力和新的惯用法；Go 程序员一直在寻找其他方法来做的事情，现在有了新的、更好的方法。Go 坚守其兼容性承诺——旧的方式将永远有效——但尽管如此，这在旧惯用法和新惯用法之间造成了分歧。现代化工具是静态分析工具，它们能识别旧的惯用法，并建议更快、更可读、更安全、更现代的替代方案，并且能一键可靠地完成。我们希望现代化工具能像 gofmt 为风格一致性所做的那样，为惯用法一致性做出贡献。我们将现代化工具集成为 IDE 的建议，在那里它们不仅能帮助开发者维护更一致的编码标准，我们相信它们还能帮助开发者发现新功能并跟上最新技术。我们相信现代化工具还能帮助 AI 编码助手跟上最新技术，并对抗它们倾向于强化关于 Go 语言、API 和惯用法的过时知识。即将到来的 Go 1.26 版本将包括对长期休眠的 go fix 命令的全面改造，使其能够批量应用全套的现代化工具，回归其Go 1.0 之前的根源。

九月底，我们与 Anthropic 和 Go 社区合作，发布了模型上下文协议（MCP）的官方 Go SDK 的 v1.0.0。这个 SDK 支持 MCP 客户端和 MCP 服务器，并支撑着 gopls 中新的 MCP 功能。将这项工作开源，有助于赋能围绕 Go 构建的日益增长的开源智能体生态系统的其他领域，例如最近由 Google 发布的Agent Development Kit (ADK) for Go。ADK Go 建立在 Go MCP SDK 之上，为构建模块化的多智能体应用程序和系统提供了一个地道的框架。Go MCP SDK 和 ADK Go 展示了 Go 在并发、性能和可靠性方面的独特优势如何使 Go 在生产级 AI 开发中脱颖而出，我们预计未来几年会有更多的 AI 工作负载用 Go 编写。

展望未来

Go 前方是激动人心的一年。

我们正在通过全新的 go fix 命令、对 AI 编码助手的更深层次支持，以及对 gopls 和 VS Code Go 的持续改进，来提升开发者的生产力。Green Tea 垃圾回收器的正式可用、对单指令多数据（SIMD）硬件功能的原生支持，以及运行时和标准库对编写能更好地扩展到大规模多核硬件代码的支持，将继续使 Go 与现代硬件保持一致，并提高生产效率。我们正专注于 Go 的“生产栈”库和诊断工具，包括由 Joe Tsai 和 Go 社区成员共同推动的、对 encoding/json 的一次大规模（且酝酿已久）的升级；由 Uber 的编程系统团队贡献的泄露 goroutine 分析；以及对 net/http、unicode 和其他基础包的许多其他改进。我们正致力于为使用 Go 和 AI 构建提供清晰的路径，谨慎地演进语言平台以适应当今开发者不断变化的需求，并构建能够同时帮助人类开发者和 AI 助手及系统的工具和能力。

在 Go 开源发布 16 周年之际，我们也在展望 Go 开源项目本身的未来。从其卑微的开端开始，Go 已经形成了一个蓬勃发展的贡献者社区。为了继续最好地满足我们不断扩大的用户群的需求，尤其是在软件行业动荡的时期，我们正在研究如何更好地扩展 Go 的开发流程——同时不失 Go 的基本原则——并更深入地让我们的优秀贡献者社区参与进来。

没有我们卓越的用户和贡献者社区，Go 就不可能有今天的成就。我们祝愿大家在新的一年里一切顺利！

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

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

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