2026-04-08 08:15:14
本文永久链接 – https://tonybai.com/2026/04/08/perspective-on-quantum-computing-timelines
大家好，我是Tony Bai。
过去三十年，我们一直活在一个笑话里：“能够破解 RSA 加密的量子计算机，永远在十年之后。”
作为一名软件工程师，我曾和你们中的大多数人一样，对所谓的“量子末日（Q-Day）”嗤之以鼻。我们觉得，在有生之年，我们赖以生存的 RSA、ECC 加密体系坚不可摧，那一天遥遥无期。
但就在昨天（2026年4月6日），这个笑话，似乎被终结了。
Go 语言前核心团队安全负责人、Go密码学专家之一 Filippo Valsorda，在他的个人博客上发表了一篇极其沉重的文章。
在文章的开头，他用一种近乎“忏悔”的口吻写道：
“在推出抗量子密码学的紧迫性上，我的立场与几个月前相比，已经发生了改变。……是时候公开表明并解释我改变想法的原因了。”
在这篇长文中，Filippo 引用了 Google 和 Oratomic 上周刚刚发表的两篇重磅论文，以及多位顶级物理学家的最新警告，最终得出了一个令整个软件工程界脊背发凉的结论：我们不再拥有十年。具备破解当前所有主流加密算法能力的量子计算机（CRQC），其到来的时间线，已经被一些顶级专家压缩到了一个令人绝望的数字——2029 年。
是的，只剩下 33 个月。
今天，就让我们跟随这位曾经的“官方守护者”的视角，看看这场已经兵临城下的“加密世界末日”，到底是怎么回事，以及我们作为普通的后端开发者，该如何在这场史无前例的迁移中生存下来。
Filippo 指出，在过去的一周里，两篇论文彻底改变了游戏规则。
第一篇，来自 Google。 这篇论文极大地修正了破解 256 位椭圆曲线（如我们每天都在用的 HTTPS 证书、比特币签名 secp256k1）所需的逻辑量子比特（qubits）和门电路数量。结论是：在超导量子比特这种高速架构上，攻击可以在几分钟内完成。
第二篇，来自 Oratomic。 这篇论文更加激进。它指出，如果拥有非局部连接能力（如中性原子方案），破解 256 位椭圆曲线甚至只需要 10,000 个物理量子比特。这种攻击虽然更慢，但哪怕一个月只能破解一个密钥，也足以引发灾难。
那张出现在论文第二页、堪称“末日倒计时”的图表，清晰地展示了攻破 RSA-2048 和 ECC-256 所需的物理量子比特数，正在以肉眼可见的速度急剧下降。
Filippo 坦言：“我不是物理学家，我看不懂论文里所有的物理学原理。但我的工作是风险评估。我知道的是，至少有一部分真正的专家正在告诉我们：硬件在变好，算法在变便宜，纠错要求在降低。一切都在加速。”
更让 Filippo 感到警惕的，不是冷冰冰的论文，而是行业顶尖精英们近乎“反常”的表态。
Filippo 写道，如果你还在想“这事儿可能成，也可能不成”，那你已经输了。
现在的赌注不是“你 100% 确定 2030 年会有量子计算机吗？”，而是“你 100% 确定 2030 年绝对不会有吗？你敢拿你所有用户的身家性命去赌那不到 1% 的可能性吗？”
为什么我们必须立刻行动？因为黑客们正在疯狂执行一种极其阴险的战略：“Store Now, Decrypt Later”（先收集，后破解，SNDL）。
他们把现在通过网络截获的、由 RSA/ECC 加密的、看似安全的核心机密数据（比如你的银行交易、公司的商业合同、国家的敏感情报）全部存储在巨大的硬盘阵列里。
等几年后量子计算机成熟，他们就能在一瞬间，把这些尘封的历史数据全部解开，一览无余。
这意味着，我们今天发送的每一封加密邮件，每一次 HTTPS 访问，都在为未来的某一次“数字考古”提供素材。
面对这场已经兵临城下的风暴，Filippo 作为Go 密码学界的专家，给出了极其具体、甚至有些“痛苦”的行动指南。
1. 密钥交换（Key Exchange）：立即迁移到 ML-KEM
这是抵御 SNDL 攻击的第一道防线。Filippo 强调，任何非抗量子的密钥交换（如经典的 ECDH）都应被视为潜在的“主动破解”行为，并像 OpenSSH 那样向用户发出明确警告。
2. 数字签名（Digital Signatures）：硬着头皮上 ML-DSA，放弃幻想
这是最痛苦的部分。Filippo 不无遗憾地承认，他原本希望我们能有更多时间去设计更优雅的、适应大签名体积的协议。但现在，没时间了。
我们必须接受 ML-DSA 签名体积巨大（几千字节，而 ECDSA 只有几十字节）的残酷现实，并开始在为小签名设计的协议（如 X.509 证书）中强行塞入这些“肥胖”的签名。
他甚至激进地提出：应该彻底放弃“混合签名”（经典+后量子）的过渡方案，直接一步到位使用纯 ML-DSA-44。因为混合签名带来的复杂性和性能开销，已经超过了它能提供的那点微不足道的“对冲”收益。
3. 对 Go 开发者意味着什么？
Filippo 直言不讳：
“在我的世界里，我们必须开始思考，Go 标准库中一半的密码学包突然变得不安全意味着什么。……这是我们职业生涯中从未遇到过的事情：从 SHA-1 到 SHA-256 的迁移，远没有这次这么具有破坏性。”
这意味着，我们很快就要在 Go 的 crypto/tls, crypto/x509, x/crypto/ssh 中看到翻天覆地的变化。
在文章的结尾，Filippo 提到，他本周刚刚开始在博洛尼亚大学教授一门密码学博士课程。他告诉学生，RSA、ECDSA 这些我们曾经引以为傲的算法，现在只能作为“遗留算法（Legacy Algorithms）”来介绍了。
他写道：“我知道，这感觉很奇怪。但，现实就是如此（it is what it is）。”
Filippo 的这声叹息，既是对一个技术时代的告别，也是对我们所有软件工程师拉响的高级别警报。
当 Go 语言前核心团队的安全负责人、一个以极度严谨和保守著称的密码学专家，都开始用如此紧迫的口吻催促我们行动时，我们没有理由再把头埋在沙子里，假装危机还很遥远。
那艘名为“量子计算”的巨轮，已经出现在了海平面上。现在不是争论它会不会撞上来的时候，现在是立刻开始造救生艇的时候。
资料链接：
今日互动探讨：
在你的公司或个人项目中，有哪些核心数据是绝对不能在 5-10 年后被解密的？面对这场迫在眉睫的密码学大迁移，你觉得我们应该从哪个环节开始着手准备？
欢迎在评论区分享你的看法和焦虑！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-04-07 08:17:15
本文永久链接 – https://tonybai.com/2026/04/07/garbage-collectors-deep-dive
大家好，我是Tony Bai。
为什么 Java 的 G1GC 需要设置停顿目标？Go 的混合写屏障是如何消除栈重扫的？Python 又是如何解决引用计数无法处理的循环引用？
垃圾回收（GC）不仅是语言运行时的核心，更是理解高性能系统绕不开的坎。
本文翻译自Shubham Raizada的文章《Garbage Collection: From First Principles to Modern Collectors in Java, Go and Python》。
此文通过对历史经典论文的溯源和对现代主流语言底层实现的拆解，构建了一套完整的 GC 知识体系。
文章涵盖了从基础的标记-清除、复制与整理算法，到复杂的三色标记抽象、写屏障机制以及有色指针技术。
无论你是想调优 JVM 性能，还是试图理解 Go 并发垃圾收集的吞吐成本，这篇文章都将为你提供从理论支撑到代码实现的全景视角。
以下是译文全文：
在过去的几年里，我的技术栈经历了从 Java 到 Go，再到 Rust，现在又回到了 Java 的过程。
在这些语言之间切换时，一直绕不开的一个话题就是垃圾回收（Garbage Collection, GC）。Java 和 Go 有 GC，而 Rust 没有。
在基准测试、延迟讨论以及“为什么这个服务变慢了”的对话中，GC 总会出现在某个角落。我经常听到关于 GC pauses（GC 停顿）、throughput overhead（吞吐量开销）和 write barriers（写屏障）的讨论，但我并不完全理解底层发生了什么。
在追溯起源时，我读到了 McCarthy 1960 年的论文，这篇论文因引入 Lisp 而闻名，但它也是首次描述 mark-and-sweep（标记-清除）的地方。
这又引导我阅读了 Wilson 1992 年的综述《Uniprocessor Garbage Collection Techniques》，该文将随后的所有发展组织成了一个清晰的分类学。
阅读这两篇文献让我更容易理解现代垃圾收集器，因为 G1GC、ZGC、Go 的并发收集器以及 CPython 的混合方案全都是这些论文所描述思想的变体。我还用 Go 编写了一个简单的玩具级 GC，以便亲自观察其机制。
以下是我在这一过程中的笔记。
这篇论文因引入 Lisp 而闻名，但垃圾回收器几乎是作为实现细节被埋藏在其中的。McCarthy 需要一种方法来管理符号表达式的内存。Lisp 程序操作的是嵌套的列表（lists of lists of lists），这种递归结构使得要求程序员手动释放内存变得不切实际。因此，他描述了一种自动执行此操作的机制。
该机制分为两个阶段。首先，从程序正在活跃使用的 root（根）变量开始，遍历它们引用的每一个对象，将每个对象标记为 reachable（可达）。其次，扫描所有内存。任何未被标记的对象都是垃圾。将它们重新添加回 free list（空闲列表）。
这就是 mark-and-sweep（标记-清除）。它能自然地处理 cycles（循环引用，因为不可达的循环永远不会被标记），不需要逐个对象的簿记工作，并让程序员可以完全忽略内存管理。
其代价是程序在收集器运行时必须完全停止。每一次分配、每一次计算，所有一切都会冻结，直到标记和清除完成。对于 McCarthy 在 1960 年编写的程序来说，这完全是合理的。
随着程序规模变大并进入对延迟敏感的环境（如处理每秒数千次请求的 Web 服务器），stop-the-world（全线停顿）成了一个难以接受的权衡。现代 GC 研究产生的大部分成果都是为了回答一个问题：如何在不停止世界的情况下进行垃圾内存回收？
到 1992 年，三十年的 GC 研究已经产生了许多想法，但缺乏统一的词汇。Wilson 的综述论文将这一切组织了起来。它不是一种新算法，而是一个分类学，为散落在几十年论文中的思想赋予了名称和结构。
Wilson 正式确立了所有后续算法构建其上的三种经典算法。
第一种是 mark-and-sweep（标记-清除），即 McCarthy 的原始算法。从 roots 开始，遍历对象图，标记你能触达的所有内容，然后扫过堆并释放任何未标记的内容。它自然处理循环引用，实现简单。缺点是经过足够多的分配和回收循环后，堆会变得 fragmented（碎片化）。存活对象最终散落在各处，中间夹杂着细小的空闲间隙，分配器(allocator)必须更费力地寻找空间。
第二种是 copying（复制算法），有时被称为 semi-space（半空间）。其想法是将堆分成两个相等的部分。你在其中一半进行分配，当它填满时，将所有存活对象拷贝到另一半，然后将第一半完全丢弃。碎片消失了，因为存活对象在拷贝过程中被紧密排列在一起。分配速度很快，因为你只需移动一个 bump pointer（碰撞指针）。代价是有一半的内存始终处于空闲状态，等待成为下一次拷贝的目标。
第三种是 reference counting（引用计数）。每个对象都记录有多少个指针指向它。当创建一个新引用时，计数增加；当移除一个引用时，计数减少。当计数归零时，对象立即被释放。没有追踪过程，没有停顿，销毁是确定性的。问题在于 cycles（循环引用）。如果两个对象相互指向，即使程序中没有任何其他部分可以触达它们，它们的计数也至少为 1。仅靠引用计数，它们永远不会被释放。
除了这三种算法，Wilson 还探讨了现代垃圾回收器赖以生存的两个观察结果。
第一个是 generational hypothesis（分代假说）：大多数对象死得早。在实践中，程序分配的临时对象（中间值、请求作用域的缓冲区、循环变量）往往很快变成垃圾，而只有一小部分对象会贯穿整个程序生命周期。如果你频繁回收年轻对象，偶尔回收老对象，你就能将大部分工作集中在堆中主要是垃圾的部分，这比每次都扫描所有内容的代价要小得多。
第二个是 tricolor marking（三色标记），这是一种用于增量和并发收集的抽象。你不再简单地将对象标记为已访问或未访问，而是使用三种颜色：white（白色，尚未见到）、grey（灰色，已见到但子节点尚未扫描）和 black（黑色，已完全处理）。收集器一次处理一个灰色对象。结束时，白色对象即为垃圾。这种抽象使得收集器和应用程序可以同时运行，而不会破坏彼此对堆的视图。Go 的并发 mark-and-sweep 和 ZGC 的并发标记都是这一思想的直接后裔。
本文“现代 GC”部分中的所有内容都可以映射回 Wilson 的分类。工程实现已经变得更加复杂，但底层结构依然如故。
几乎所有的垃圾回收器要么是 reference counting（引用计数），要么是 tracing（追踪），或者是两者的某种结合。Wilson 的论文围绕这一划分进行组织，三十年后依然成立。
每个对象维护一个指向它的引用计数。当引用创建时，计数增加。当引用移除时，计数减少。当计数归零时，对象立即被释放。
这是 CPython 所使用的其主要机制。它很简单，并能提供确定性的销毁。当指向文件句柄的最后一个引用消失时，del 运行，文件当场关闭，而不是在以后的某个 GC cycle中。
有两个问题使得引用计数无法独立胜任。
Cycles (循环引用)。 如果对象 A 指向对象 B，且对象 B 指向 A，那么即使程序中没有任何其他部分能触达它们，两者的计数也至少为 1。两者都不会被释放。
这并非理论上的边缘案例。循环引用在链表数据结构、父子关系、观察者模式和缓存中自然出现。稍后在介绍 CPython 的 GC 时，我将讨论 Python 如何处理这个问题。
Per-mutation overhead (每次修改的开销)。 每次指针赋值都需要更新引用计数。在多线程程序中，这些必须是 atomic（原子）操作，成本昂贵得多。每当你将对象传递给函数、返回它或将其赋值给字段时，你都要支付这种代价。
追踪式收集器不跟踪单个引用，而是从一组已知的存活引用（称为 root set，根集合）开始，遍历整个对象图。它能触达的每个对象都被标记为存活。其他所有对象都被释放。
Root set 是起点，因此什么算作 root（根）至关重要。不同语言的答案是相同的：root 是 runtime（运行时）无需追踪就能找到的任何引用。这些指针锚定在程序当前的执行状态中，是在任何遍历开始之前你就知道是存活的东西。
在实践中，roots 分为以下几类。
每个活跃 stack frame（栈帧）中的 local variables（局部变量）和函数参数都是 roots。程序正在活跃地运行这些函数，因此它们引用的任何内容定义上都是在使用中的。
Global and static variables（全局变量和静态变量）是 roots，因为它们在程序的整个生命周期内都存在。
CPU registers（CPU 寄存器）是 roots。因为当 JIT 编译器优化一个热点方法时，它可能会将频繁访问的对象引用保留在 CPU 寄存器中，而不是写回栈。如果 GC 此时运行，寄存器保存着该对象的唯一存活引用。如果 GC 不扫描寄存器，它就会释放一个仍在使用中的对象。为了防止这种情况，运行时在代码中定义了 safe points（安全点），GC 只能在这些点发生，并且在这些点，它会快照寄存器状态以寻找持有的任何引用。
Runtime（运行时）本身也持有与用户代码无关的 roots。在 JVM 中，class loaders 是 roots：你加载的每个类都由其类加载器引用，只要类加载器存活，它加载的每个类（包括它们的静态字段）就保持存活。Interned strings（常量池字符串）是 roots，因为 String.intern() 将字符串存储在 JVM 维护的共享池中。JNI handles 是 roots，因为当原生 C 或 C++ 代码通过 Java Native Interface 持有 Java 对象的引用时，该引用存在于 Java 堆外的句柄表中，GC 必须扫描它。每个活跃线程都是一个 root，其整个调用栈帧都是 root set 的一部分。
Go 的运行时遵循同样的原则。每个 goroutine 都有自己的栈，必须扫描所有 goroutine 栈以寻找 roots。运行时还跟踪自己的内部数据结构，例如 finalizer 队列，作为 root set 的一部分。
核心见解是：roots 是由运行时在无需追踪的情况下就已经知道是存活的东西定义的。其他所有东西必须通过从 root 可达来证明自己的生存权。这就是为什么这个概念是与语言无关的。Java、Go 和 Python 之间的具体 roots 集合有所不同，但原则是一样的：从你知道是存活的地方开始，向外追踪，并回收其余部分。
循环引用被自然处理。如果 A 和 B 相互指向，但都无法从任何 root 到达，则标记阶段永远不会访问它们。它们保持未标记状态并被清除。
代价：朴素的 mark-and-sweep 必须在追踪堆时暂停整个程序。这种 stop-the-world（全线停顿）是早期垃圾回收器的核心问题，也是现代 GC 几十年来工程化改进的重点。
在具有高分配速率的服务器工作负载中，引用计数的逐次修改成本会积少成多。每次指针写入都会增减计数。在多线程程序中，这些更新必须是原子的，而原子操作很昂贵。在数十个线程中每秒进行数千次分配时，这种开销变得可衡量。此外，循环引用问题无论如何都需要一个补充的追踪步骤。而且追踪式收集器可以做成并发的，在应用程序运行的同时运行，只有简短的停顿。
Java 和 Go 使用追踪式收集器。Python 是一个显著的例外，它以引用计数为基础，并在此之上增加了一层用于追踪循环引用的检测器。
Wilson 的论文描述了实现追踪的四种方式，每种方式都有不同的权衡。
最简单的追踪式收集器。分为两个阶段：
Mark-sweep 的主要问题是 fragmentation（碎片化）。经过足够的回收周期后，堆看起来就像瑞士奶酪：存活对象散布其间，中间有很小的空闲间隙。你总共可能有 100MB 空闲内存，但没有一个连续的块大到足以满足一次新分配。分配器必须维护一个 free list 并搜索合适的空间，随着堆变得碎片化，这会变慢。
堆被分成两个相等的一半：from-space（源空间）和 to-space（目标空间）。分配发生在 from-space，使用简单的 bump pointer（碰撞指针）。当 from-space 填满时，收集器将所有存活对象拷贝到 to-space，更新所有指针，然后交换两者的角色。旧的 from-space 被完全丢弃。
分配速度极快，因为它只是一个指针移动。Compaction（压缩）自然发生。代价是任何时候只有一半的堆可用。
标记阶段与 mark-sweep 相同，但收集器不是简单地释放未标记的对象，而是将所有存活对象滑动到堆的一端。这消除了碎片，且没有复制算法 50% 的内存开销。
缺点是整理需要对堆进行多次扫描：一次标记，一次计算新地址，一次更新所有指针，一次移动对象。
Wilson 论文中最具影响力的观察之一是弱分代假说：大多数对象死得早。
在典型的 Web 服务器中，每个请求都会创建临时对象（解析器、中间字符串、响应构建器），它们只存活几毫秒。配置对象、连接池和缓存则贯穿整个应用程序生命周期。
分代收集器利用这一点，将堆划分为 generations（代）。新对象进入 young generation（年轻代）。如果它们在几次回收中幸存下来，就会被提升到 old generation（老年代）。年轻代回收频繁且速度快，因为那里的大多数对象已经死了。老年代回收较少发生。
Eden 是所有新对象出生的地方。每一个 new Object() 都去这里。它很快就会填满，因为大多数程序分配速率很高。
S0 和 S1 是两个较小的 survivor spaces（幸存者空间）。当 Eden 填满并运行 minor GC（次要回收）时，收集器将 Eden 中的每个存活对象拷贝到其中一个空间（比如 S0）。下一次回收时，来自 Eden 和 S0 的幸存者被拷贝到 S1。再下一次，回到 S0。它们在每个周期轮换。这是年轻代中的复制算法：没有碎片，没有空闲列表，只有两半空间轮流充当目标。代价是你需要两个幸存者空间，但它们保持得很小，因为到回收运行时，Eden 中的大多数对象都已经死了。
Promotion to old generation (提升到老年代)。 在对象在 S0 和 S1 之间反弹足够多次之后（JVM 中的默认阈值是 15 次），收集器认定它已赢得了一席之地，并将其提升到老年代。老年代回收频率低得多，并且使用更重的算法（标记-整理而非复制），因为那里的对象庞大且长寿。
关键的实现挑战是跟踪从老对象到新对象的引用。如果一个老对象指向一个年轻对象，即使没有年轻代 root 指向它，该年轻对象也绝不能被回收。这通过 write barrier（写屏障）解决，即在每次指针写入时注入的一小段代码，用于在 remembered set（记录集）中记录跨代引用。
我写了一个极简的 mark-and-sweep 收集器来使这些概念具体化。它大约有 70 行代码，演示了完整循环：分配对象、构建对象图、从 roots 标记以及清除不可达对象。
package main
import "fmt"
// Object 代表一个在堆上分配的对象。
type Object struct {
name string
marked bool
children []*Object
}
// VM 是一个带有垃圾回收器的微型虚拟机。
type VM struct {
heap []*Object
roots []*Object // 模拟栈变量和全局变量
}
// NewObject 在 VM 的堆上分配一个对象。
func (vm *VM) NewObject(name string) *Object {
obj := &Object{name: name}
vm.heap = append(vm.heap, obj)
return obj
}
// mark 从每个 root 开始遍历并标记所有可达对象。
func (vm *VM) mark() {
for _, root := range vm.roots {
vm.markObject(root)
}
}
func (vm *VM) markObject(obj *Object) {
if obj == nil || obj.marked {
return
}
obj.marked = true
for _, child := range obj.children {
vm.markObject(child)
}
}
// sweep 释放未标记的对象并重置幸存者的标记。
func (vm *VM) sweep() {
alive := []*Object{}
for _, obj := range vm.heap {
if obj.marked {
obj.marked = false // 为下一个 GC 周期重置
alive = append(alive, obj)
} else {
fmt.Printf(" collected: %s\n", obj.name)
}
}
vm.heap = alive
}
// GC 运行一次完整的 mark-and-sweep 回收。
func (vm *VM) GC() {
fmt.Printf("gc: heap has %d objects\n", len(vm.heap))
vm.mark()
vm.sweep()
fmt.Printf("gc: %d objects remain\n\n", len(vm.heap))
}
func main() {
vm := &VM{}
a := vm.NewObject("A")
b := vm.NewObject("B")
c := vm.NewObject("C")
_ = vm.NewObject("D") // 已分配但从未链接到任何东西
// 构建图: A -> B -> C
a.children = append(a.children, b)
b.children = append(b.children, c)
// 只有 A 是 root
vm.roots = append(vm.roots, a)
fmt.Println("=== GC #1: D is unreachable ===")
vm.GC()
// 创建循环: C -> A, 然后移除所有 roots
c.children = append(c.children, a)
vm.roots = nil
fmt.Println("=== GC #2: A->B->C->A cycle, no roots ===")
vm.GC()
}
运行结果：
=== GC #1: D is unreachable ===
gc: heap has 4 objects
collected: D
gc: 3 objects remain
=== GC #2: A->B->C->A cycle, no roots ===
gc: heap has 3 objects
collected: A
collected: B
collected: C
gc: 0 objects remain
第一次回收：A、B 和 C 通过 root A 可达。D 没有任何 root 路径，因此被回收。
第二次回收：A、B 和 C 形成了一个循环（A->B->C->A），但没有 roots。标记阶段从未访问过它们中的任何一个。所有三个都被清除了。这正是击败引用计数的场景。循环中的每个对象都有非零的引用计数，但没有一个能从 root 到达。
追踪式 GC 不关心循环。它们只关心从 roots 开始的可达性。
有一点需要注意：markObject 函数使用了递归，这在深层对象图上会耗尽栈空间。真实的垃圾回收器使用显式的 worklist（工作列表）而不是调用栈。
上面的玩具收集器为了整个标记和清除过程停止了世界。现代 GC 已经进化到在应用程序持续运行的同时并发完成大部分工作。
Go 的垃圾回收器是非分代的、非整理的且并发的。它不按年龄区分对象，也不在内存中移动对象。其重点是保持低停顿时间。
收集器使用三色抽象（tri-color abstraction）进行并发标记。每个对象处于三种状态之一：
收集器开始时将所有对象设为白色，然后将 roots 设为灰色，并处理灰色对象直到不再剩余。所有仍为白色的内容都被清除。
开始: 所有对象为白色，roots 为灰色
步骤 1: 选取一个灰色对象，扫描其子节点
- 将子节点标为灰色
- 将扫描过的对象标为黑色
步骤 2: 重复直到没有灰色对象剩余
步骤 3: 所有白色对象都是垃圾
示例:
Roots: [A]
开始: A(grey) --> B(white) --> D(white)
A(grey) --> C(white)
扫描 A: A(black) --> B(grey) --> D(white)
A(black) --> C(grey)
扫描 B: A(black) --> B(black) --> D(grey)
A(black) --> C(grey)
扫描 C: A(black) --> B(black) --> D(grey)
A(black) --> C(black)
扫描 D: A(black) --> B(black) --> D(black)
A(black) --> C(black)
结果: 任何剩余的白色对象都是垃圾并被释放
难点在于应用程序在收集器遍历时持续运行并修改指针。这造成了一个需要仔细处理的正确性问题。
收集器认为黑色对象已完成。一旦对象变黑，收集器就不会再扫描它。它的所有子节点都已被访问并设为灰色。但是，如果应用程序在收集器仍在运行时，将一个指向白色对象的指针写入黑色对象，收集器就有麻烦了。黑色对象已经处理完了。该白色对象也无法从任何灰色对象触达。当标记阶段结束并清除运行时，该白色对象将被释放，即便有一个存活的黑色对象指向它。
这被称为 tricolor invariant（三色不变性）：黑色对象绝不能直接指向白色对象。如果发生了这种情况，白色对象对收集器是不可见的，会被错误释放。write barrier（写屏障）的存在专门用于在并发标记期间应用程序修改对象图时维护这一不变性。
Go 通过 hybrid write barrier（混合写屏障，Go 1.8 引入）解决了这个问题。要理解它为什么有效，看看它结合的两种旧屏障会有所帮助。
Dijkstra’s 插入屏障 (1978)：每当一个指针被写入对象时，将新的被引用者设为灰色。如果一个黑色对象存储了对白色对象的引用，该白色对象会在收集器错过它之前变灰。这维护了三色不变性。
问题在于 goroutine 栈与堆对象不同。编译器在堆指针写入处注入写屏障，例如写入结构体字段或切片元素。栈写入是局部变量赋值，编译器对其分别处理。在每一个局部变量赋值上放屏障会使函数调用和基本操作变得极其昂贵，所以屏障不覆盖它们。这意味着在并发标记期间，goroutine 可以自由地将指向白色对象的指针写入局部变量，而没有屏障触发。收集器不知道发生了这事。
为了修复这一点，在并发标记结束时，Go 曾经必须停止世界并从头重新扫描每个 goroutine 的整个栈。重新扫描时发现的任何指向白色对象的指针都会变灰，防止它们被错误释放。此步骤的停顿时间随着 goroutine 数量和其栈大小而增加。拥有成千上万个 goroutine 的程序可能会看到数毫秒的 STW 停顿，仅仅是为了这次重新扫描。这是 Go 1.8 之前主要的 STW 停顿来源。
Yuasa’s 删除屏障 (1990) 采取相反的方法：每当一个指针即将被覆盖时，在旧引用消失前将其变灰。这确保了在标记开始时可达的任何东西直到结束都保持可达，即便应用程序在标记期间丢弃了它的引用。缺点是标记期间死亡的一些对象会存活到下一个周期（floating garbage，浮动垃圾），因为屏障保守地让它们活着。
Go 的混合屏障结合了两者。在堆写入时，它同时应用两种屏障：将旧引用变灰（Yuasa）并将新引用变灰（Dijkstra）。在栈写入时，不运行屏障，但栈上新分配的对象开始时就是黑色而不是白色。这种组合赋予了收集器足够强的不变性，使其在标记结束时永远不需要重新扫描栈。STW 停顿从几十毫秒降到了不到一毫秒。
// 混合屏障在堆指针写入时的逻辑:
// *slot = new_ptr
shade(*slot) // 将旧引用变灰 (Yuasa: 不要丢掉之前在那里的内容)
shade(new_ptr) // 将新引用变灰 (Dijkstra: 不要错过新到来的内容)
*slot = new_ptr
这就是并发垃圾回收的吞吐量成本：标记阶段的每一次堆指针写入都要运行此 shade 逻辑。单次操作开销虽小，但在高分配速率下会累积。权衡的结果是你获得了亚毫秒级的 STW 停顿，而不是几十毫秒。
Go 仅简短地停止世界以扫描 goroutine 栈并切换写屏障的开关。实际的标记和清除与应用程序并发进行。
No compaction (无整理)。 Go 在分配后不移动对象。相反，Go 使用 tcmalloc 风格的分配器，将内存划分为 size classes（大小类），并从每个处理器的缓存（per-processor caches）中分配。对象被分组为固定的大小类（8 字节、16 字节、32 字节，最高达 32 KB）。分配时从空闲列表中选取合适大小的槽。这减少了碎片而无需移动对象，但并不能完全消除碎片。
No generational collection (无分代收集)。 Go 团队的理由是，考虑到 Go 典型的带有 goroutine 和并发工作负载的分配模式，分代 GC 增加的复杂性（用于跟踪老到新指针的写屏障、提升逻辑、分代大小调优）带来的收益是不确定的。Go 通过使其并发标记器足够快来补偿，从而使额外的回收频率变得可以接受。
关键里程碑：
GOGC 调节旋钮。 Go 提供了一个主要的调优参数：GOGC。它控制在下一次 GC 触发之前堆可以增长多少。默认值是 100，意味着当堆自上次回收以来翻倍时触发 GC。
GOGC=100 (默认):
GC 后，存活堆 = 500MB
下次 GC 触发点: 500MB * (1 + 100/100) = 1000MB
GOGC=50 (更激进):
GC 后，存活堆 = 500MB
下次 GC 触发点: 500MB * (1 + 50/100) = 750MB
GOGC=200 (较保守):
GC 后，存活堆 = 500MB
下次 GC 触发点: 500MB * (1 + 200/100) = 1500MB
更低的 GOGC 意味着更频繁的回收（更低的内存占用，更高的 CPU 开销）。更高的 GOGC 意味着较少的回收（更高的内存占用，更低的 CPU 开销）。
Go 1.19 增加了 GOMEMLIMIT，这是一个软内存限制。在具有硬性内存预算的容器环境中，GOMEMLIMIT 告诉 GC pacer（步调算法）在内存使用接近限制时变得更加激进。
亲自尝试：
package main
import (
"fmt"
"runtime"
"time"
)
var longLived []*[1024 * 1024]byte
func main() {
fmt.Println("Go version:", runtime.Version())
for round := 0; round < 50; round++ {
// 短寿对象: 分配小对象，让它们死亡
for i := 0; i < 5000; i++ {
_ = make([]byte, 1024)
}
// 长寿对象: 每 10 轮保留一个
if round%10 == 0 {
arr := new([1024 * 1024]byte)
longLived = append(longLived, arr)
}
time.Sleep(50 * time.Millisecond)
}
var stats runtime.MemStats
runtime.ReadMemStats(&stats)
fmt.Printf("Total GC cycles: %d\n", stats.NumGC)
fmt.Printf("Total STW pause: %v\n", time.Duration(stats.PauseTotalNs))
fmt.Printf("Long-lived objects: %d\n", len(longLived))
}
运行并开启 GC 追踪：
GODEBUG=gctrace=1 go run gcdemo.go
观察输出内容：
gc 1 @0.011s 1%: 0.044+0.56+0.13 ms clock, 0.62+0.21/0.57/0+1.8 ms cpu, 3->4->0 MB, 4 MB goal, 0 MB stacks, 0 MB globals, 14 P
从左到右阅读：
0.044+0.56+0.13 ms clock: GC 周期的三个阶段：STW 标记开始 (0.044ms) + 并发标记和扫描 (0.56ms) + STW 标记结束 (0.13ms)。STW 停顿是 clock 字段中的第一个和第三个数字。在此例中，应用程序被冻结的总墙钟时间是 0.044 + 0.13 = 0.174ms。中间的 0.56ms 是并发的：你的应用程序一直在运行。在 Go 中，STW 停顿通常在 1ms 以下，往往远低于 0.1ms。
0.62+0.21/0.57/0+1.8 ms cpu: CPU 时间细目。格式为：STW-开始 + 辅助/背景/空闲 + STW-结束。每个数字代表：
当多个核心并行工作时，CPU 时间可以超过墙钟时间。并发阶段的 CPU 时间可能少于墙钟时间，因为 GC 与你的应用程序共享核心。
G1GC 自 JDK 9 以来一直是 Java 的默认垃圾回收器。它是一个分代的、基于区域（region）的收集器。它进行追踪、标记和整理，但它是增量式进行的，而不是一次性完成。
Region layout (区域布局)。 G1 将堆划分为大小相等的区域，通常每个区域为 1MB 到 32MB，取决于堆的大小。每个区域在任何时候扮演四种角色之一：Eden（伊甸园）、Survivor（幸存者）、Old（老年代）或 Humongous（巨型对象，用于超过半个区域大小的对象）。区域的角色可以在不同回收周期之间改变。
Young collection (次要 GC)。 Eden 区域填满。G1 停止世界，使用并行多线程标记器标记 Eden 和 Survivor 区域中的存活对象，将幸存者拷贝到新的 Survivor 区域或提升到 Old 区域，并完全丢弃旧的 Eden 区域。这是一个并行的 STW 停顿，但很短，因为年轻代区域较小且年轻对象大多已死。
Mixed collection (混合回收)。 G1 周期性地运行并发标记周期，以找出哪些老年代区域包含的垃圾最多。然后运行混合回收：同时疏散（evacuating）年轻代区域和最具“盈利价值”的老年代区域。这就是“Garbage First”名称的由来。G1 总是优先选取垃圾密度最高的老年代区域，从而在单位停顿时间内实现最大的回收量。
SATB (Snapshot-At-The-Beginning，起始快照)。 在并发标记期间，应用程序持续运行并修改对象图。G1 使用 SATB 维护正确性。在标记开始时，G1 对哪些对象存活进行逻辑快照。该快照中存活的对象在此周期被视为存活，即使应用程序在标记期间丢弃了它们。写屏障将修改字段的旧值记录到 SATB 队列中。这种做法是保守的（一些垃圾会存活到下个周期），但是正确的。
并发标记正在运行。应用程序执行：
obj.field = null (原本指向 X)
没有 SATB: X 可能没有其他引用，未被标记，在使用中被释放。
有 SATB: 写屏障记录“此处曾有 X”，将 X 标为灰色。安全。
Pause target (停顿目标)。 你可以通过 -XX:MaxGCPauseMillis 配置 G1 的目标最大停顿时间。默认值是 200ms。G1 通过调整区域数量、回收集合大小和时机，尝试将停顿保持在目标范围内。它并不总是能成功，特别是在 Full GC 期间，但它是主要的调优旋钮。
亲自尝试：
import java.util.ArrayList;
import java.util.List;
public class GCDemo {
static List<byte[]> longLived = new ArrayList<>();
public static void main(String[] args) throws InterruptedException {
System.out.println("Starting GC demo...");
for (int round = 0; round < 50; round++) {
// 短寿对象：创建并立即丢弃
for (int i = 0; i < 1000; i++) {
byte[] tmp = new byte[10 * 1024]; // 每个 10KB
}
// 长寿对象：保留一些对象以构建老年代
if (round % 5 == 0) {
longLived.add(new byte[1024 * 1024]); // 1MB
}
Thread.sleep(50);
}
System.out.println("Done. Long-lived objects: " + longLived.size());
}
}
使用 G1GC 日志运行：
# 编译
javac GCDemo.java
# 使用 G1GC (Java 9+ 默认) 并开启 GC 日志
java -Xmx256m \
-XX:+UseG1GC \
"-Xlog:gc*:file=gc_g1.log:time,uptime,level,tags" \
GCDemo
# 或者，使用简洁的一行输出
java -Xmx256m -Xlog:gc GCDemo
观察日志：
[0.005s][info][gc] Using G1
[0.135s][info][gc] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 26M->3M(256M) 0.644ms
[0.812s][info][gc] GC(1) Pause Young (Normal) (G1 Evacuation Pause) 132M->7M(256M) 0.707ms
[1.710s][info][gc] GC(2) Pause Young (Normal) (G1 Evacuation Pause) 165M->13M(256M) 1.019ms
[2.528s][info][gc] GC(3) Pause Young (Normal) (G1 Evacuation Pause) 171M->19M(256M) 0.964ms
阅读日志：
ZGC 自 Java 11 起可用，并在 Java 15 中达到生产就绪状态。扩展了分代收集的 Generational ZGC 在 Java 21 中引入。ZGC 的目标是无论堆大小如何（包括数百 GB 的堆），停顿时间均保持在亚毫秒级。
G1 在年轻代回收时停顿较短，但随着堆的增长，在并发标记设置和混合回收期间会有更长的停顿。ZGC 的方法不同：它几乎将所有工作（标记、重定位、引用处理）并发进行，将 STW 工作降至最低。
Colored pointers (有色指针)。 ZGC 直接在指针位中编码 GC 元数据。在 64 位平台上，指针宽度为 64 位，但你实际上并不需要所有 64 位来寻址内存。2^42 就能给你 4TB 的可寻址空间，这超出了大多数应用程序的使用范围。这使得每个指针中留有超过 20 位空闲。ZGC 重新利用其中一些空闲位，直接在指针内部存储 GC 状态。
每个元数据位都有特定用途：
M0 和 M1 (标记位)： 用于跟踪对象是否已被标记为存活。ZGC 在每个 GC 周期中交替使用 M0 和 M1。在周期 1，收集器对每个可达对象设置 M0。在周期 2，它改用 M1。这样收集器就能区分“本周期标记”和“上个周期标记”，而无需在周期之间清除所有标记位。
Remap (R，重映射)： 此位跟踪在对象重定位（relocated）后指针是否已更新。在并发重定位期间，ZGC 将对象移动到新地址，但并不立即更新堆中的每一个指针。相反，它保留旧指针，并使 remap 位处于未设置状态。当应用程序加载这些过时指针之一时，load barrier（读屏障/加载屏障）会注意到 remap 位未设置，并对其进行修正。
Finalizable (F)： 表示该对象具有一个需要在释放前运行的 finalizer。
巧妙之处在于元数据随指针移动。GC 不需要一个单独的侧表来查找对象的 GC 状态。每个指针都已经携带了它。
Load barriers (加载屏障)。 每次应用程序从堆加载引用时，ZGC 都会插入一个加载屏障。屏障检查指针的颜色位，如果它们不处于预期状态，则采取行动。
以下是实际操作中的情况。假设收集器在并发重定位阶段将一个对象从地址 0×1000 移动到了 0×2000。应用程序仍然持有一个地址为 0×1000 且 remap 位未设置的指针。
应用程序代码:
Object x = obj.field;
实际执行的内容:
raw_ptr = load obj.field // raw_ptr = 0x1000, remap bit = 0
if (raw_ptr.color != expected) { // remap bit 为 0, expected 为 1 → 进入 slow path
new_addr = forwarding_table[0x1000] // 查找: 对象已移动到 0x2000
raw_ptr = set_address(raw_ptr, 0x2000)
raw_ptr = set_remap_bit(raw_ptr)
obj.field = raw_ptr // 就地修正指针，以便下次使用
}
x = raw_ptr // x 现在指向 0x2000
下次任何线程加载 obj.field 时，remap 位已经设置好了。屏障检查通过 fast path，没有额外工作。过时指针在第一次访问时被惰性修正。
这是关键机制。与其像 G1 在疏散期间那样让 GC 停止世界以一次性更新所有指向重定位对象的指针，ZGC 让应用程序在遇到指针时逐个修正。代价是每次指针加载都要支付屏障检查的开销，即便没有任何东西被重定位。在实践中，fast path（检查几位）执行代价足够小，与避免 STW 重定位停顿带来的收益相比，开销很小。
Concurrent relocation (并发重定位)。 G1 停止世界以将存活对象从回收区域中疏散。ZGC 在应用程序运行的同时重定位对象。它能做到这一点是因为加载屏障处理了指针修正。在启动和结束每个阶段（标记开始、标记结束、重定位开始）时有简短的 STW 停顿，但这些通常远低于 1ms。拷贝对象和修正指针的实际工作是并发发生的。
Generational ZGC (Java 21+)。 最初的 ZGC 不按年龄划分堆。分代 ZGC 增加了年轻代和老年代，同时保留了亚毫秒级停顿的保证。它更频繁地回收年轻区域（垃圾最多的地方），较少回收老年代区域。加载屏障和有色指针机制被扩展以处理分代写屏障。
何时使用 ZGC vs G1：
亲自尝试：
# 使用 ZGC 运行
java -Xmx256m \
-XX:+UseZGC \
"-Xlog:gc*:file=gc_zgc.log:time,uptime,level,tags" \
GCDemo
# 使用分代 ZGC (Java 21+)
java -Xmx256m \
-XX:+UseZGC -XX:+ZGenerational \
-Xlog:gc \
GCDemo
观察日志：
[0.318s] GC(0) Garbage Collection (Warmup) 28M(11%)->12M(5%)
[0.321s] GC(0) Pause Mark Start 0.023ms
[0.489s] GC(0) Concurrent Mark 168.123ms
[0.491s] GC(0) Pause Mark End 0.019ms
[0.492s] GC(0) Concurrent Select Relocation Set 1.234ms
[0.502s] GC(0) Concurrent Relocate 10.456ms
STW 停顿是标记为“Pause”的行。其他所有内容都是并发的。将此处的停顿持续时间与 G1 的输出进行对比。
CPython（Python 的参考实现）是“追踪式收集器占主导”模式的主要例外。它使用引用计数作为主要机制，并在之上增加了一层用于追踪循环引用的检测器。
CPython 中的引用计数。
每个 Python 对象都有一个 ob_refcnt 字段。Python 的 C API 在 Py_INCREF 时增加，在 Py_DECREF 时减少。当计数归零时，对象在 _Py_Dealloc 中被立即释放。这赋予了 Python 确定性的销毁：del 方法和上下文管理器的 exit 调用在最后一个引用掉落的那一刻发生。
import sys
x = []
print(sys.getrefcount(x)) # 2: 1个来自x，1个来自getrefcount参数本身的临时引用
y = x
print(sys.getrefcount(x)) # 3: 1个x, 1个y, 1个getrefcount参数
del y
print(sys.getrefcount(x)) # 2: 回到1个x, 1个getrefcount参数
循环引用问题。 仅靠引用计数无法回收循环垃圾。
import gc
# 创建循环引用
class Node:
def __init__(self, name):
self.name = name
self.ref = None
a = Node("A")
b = Node("B")
a.ref = b
b.ref = a # cycle: A -> B -> A
# a 和 b 的计数都 >= 1（由于相互引用）。
# 仅靠引用计数，两者都不会被释放。
del a
del b
# a 和 b 依然存活！Refcount: A 为 1 (来自 b.ref), B 为 1 (来自 a.ref)
# 显式触发循环检测器
collected = gc.collect()
print(f"Collected {collected} objects") # 收集了 4 个对象 (2个node + 2个dict)
引用计数处理了常见情况，但它无法收集循环引用。CPython 的答案是运行在引用计数系统之上的独立循环检测器。其实现在 Modules/gcmodule.c 中。
循环检测器是一个追踪式收集器，但它并不追踪整个堆。它仅跟踪能够参与循环引用的对象：如列表、字典、集合及用户自定义类实例等容器对象。字符串和整数无法持有对其他对象的引用，因此无需跟踪它们。
与 Java 的收集器一样，循环检测器使用分代方法。共有三代，编号为 0、1 和 2。思路与我们之前讨论的分代假说相同：大多数对象死得早，所以经常检查年轻对象，少打扰老对象。默认阈值硬编码在 CPython 的 Modules/gcmodule.c 中：
struct gc_generation generations[NUM_GENERATIONS] = {
/* PyGC_Head, threshold, count */
{ {(uintptr_t)_GEN_HEAD(0), (uintptr_t)_GEN_HEAD(0)}, 700, 0},
{ {(uintptr_t)_GEN_HEAD(1), (uintptr_t)_GEN_HEAD(1)}, 10, 0},
{ {(uintptr_t)_GEN_HEAD(2), (uintptr_t)_GEN_HEAD(2)}, 10, 0},
};
你可以验证你的运行时实际使用的是什么：
python3 -c "import gc; print(gc.get_threshold())"
# (700, 10, 10)
请注意，某些框架和发行版会在启动时通过 gc.set_threshold() 覆盖这些默认值，因此你的环境可能显示不同的值。
第 0 代持有新分配的容器对象。当自上次回收以来的新分配数量超过阈值（默认 700）时，回收第 0 代。幸存的对象被提升到第 1 代。在第 0 代被回收 10 次后，第 1 代被回收一次。幸存者移至第 2 代。在第 1 代被回收 10 次后，第 2 代被回收一次。
效果是第 0 代大约每 700 次分配回收一次，第 1 代大约每 7,000 次，第 2 代大约每 70,000 次。进入第 2 代的长寿对象几乎永远不会被打扰。检测器将其大部分时间花在最年轻的对象上，这些对象最有可能最近变成了垃圾。
你可以看到这些计数：
import gc
# 当前各代阈值
print(gc.get_threshold()) # (700, 10, 10)
# 当前分配计数: (gen0分配, 自上次gen1回收以来的gen0回收数, 自上次gen2回收以来的gen1回收数)
print(gc.get_count()) # 例如 (342, 8, 2)
# 强制进行全量回收
gc.collect()
# 完全禁用循环检测器 (如果你确定代码中没有循环引用)
gc.disable()
当检测器在某一代码代上运行时，它需要找出哪些对象仅被循环引用保持存活。通过一个例子更容易理解算法。
假设检测器正在查看三个被跟踪的对象：X、Y 和 Z。X 指向 Y 和 Z。Y 指回 X。还有一个局部变量持有对 X 的引用。
步骤 1：拷贝引用计数。X=2, Y=1, Z=1。
步骤 2：减去内部引用。Y 指向 X，所以从 X 的副本中减 1 (X 从 2 变为 1)。X 指向 Y，所以从 Y 的副本中减 1 (Y 从 1 变为 0)。X 指向 Z，所以从 Z 的副本中减 1 (Z 从 1 变为 0)。
步骤 3：检查剩余部分。X 的调整后计数为 1。被跟踪集合之外的某些东西（局部变量）仍然指向它。X 存活。Y 和 Z 虽然调整后计数为 0，但它们可以从 X 到达，因此它们也幸存下来。
现在想象局部变量消失了。X 的引用计数掉到 1 (只有 Y 指向它)。运行相同算法：拷贝 X=1, Y=1, Z=1。减去内部引用：X 变为 0, Y 变为 0, Z 变为 0。每个调整后的计数都是零。被跟踪集合之外没有任何东西指向它们。它们仅因彼此而存在。三者都是垃圾。
这就是核心思想。算法寻找那些存在的唯一理由是同一集合中其他对象的目标。
有一个边缘案例困扰了多年：finalizers（终结器）。
终结器是运行时在对象被销毁前调用的方法，给予其清理外部资源（如文件句柄或网络连接）的机会。在 Python 中，这就是 del 方法。
假设 A 和 B 处于循环中，且两者都有 del 方法。检测器知道它们是垃圾，但要释放它们，它需要打破循环。问题是：哪个 del 先运行？如果你先运行 A 的终结器，而它尝试使用 B，但 B 已经正在被销毁，你就会崩溃。如果你先运行 B 的，而它使用 A，同样的问题。没有安全的顺序。
在 Python 3.4 之前，CPython 直接放弃处理这些对象。它将它们放入名为 gc.garbage 的列表中，且永远不释放它们。如果你的代码创建了带有 del 的循环引用，你就会有一个静默的内存泄漏。PEP 442 通过在打破任何引用之前调用终结器修复了这个问题。当 A 和 B 的 del 运行时，两者都保持完整。只有在所有终结器执行完毕后，检测器才会打破循环并释放对象。
关于 CPython 的内存模型还有一件事值得了解。每当 Python 执行类似 x = some_object 的操作时，它会增加 some_object 的引用计数（C 语言中的 Py_INCREF）。每当变量超出作用域时，它减少计数 (Py_DECREF)。在 C 中这些是普通的整数操作：refcount += 1, refcount -= 1。没有锁，没有原子指令。
在多线程程序中，这是一个问题。两个线程可能同时增加同一个对象的引用计数。如果没有同步，一个增加操作会丢失（经典的竞态条件），之后该对象可能会在有人仍在使用时被释放。
GIL (全局解释器锁) 防止了这种情况。一次只有一个线程执行 Python 字节码，因此两个线程永远不会同时修改同一个引用计数。GIL 免费使所有引用计数操作变得安全，而无需任何原子指令。
这也是移除 GIL 如此困难的原因。如果拿掉它，整个代码库中的每一个 Py_INCREF 和 Py_DECREF 都需要变成原子操作。原子操作比普通整数增量要昂贵得多。Python 3.13 开始附带实验性的 free-threaded 模式，它使用 biased reference counting（偏向引用计数）来降低这种成本：创建对象的线程可以对引用计数进行廉价的非原子更新，只有访问该对象的其他线程才支付原子操作的代价。
每一种现代垃圾回收器都可以映射回 Wilson 在 1992 年描述的两个家族。它们之间的区别在于关于如何最小化停顿、处理并发以及高效管理内存的工程决策。
从这一对比中可以观察到几点：
Wilson 的追踪式家族在服务器运行时占据主导地位。 引用计数用于 Swift、Python 和 Rust 的 Arc，但对于具有高分配速率的托管运行时，追踪式收集器是标准做法。循环引用问题无论如何都需要补充追踪步骤，这增加了复杂性，且无法消除每次修改时的引用计数开销。
分代收集除 Go 以外随处可见。 Java 重度利用了分代假说。Python 的循环检测器使用了三代。Go 最初选择不使用分代收集，因为跨代指针写屏障的开销对 Go 的典型工作负载来说不划算。这种情况可能正在改变：最近的 Go 版本中已经开发了实验性的分代支持。
Compaction (整理) vs No compaction 是一个真正的设计分歧点。 Java 收集器进行整理，这允许 bump-pointer 分配（非常快）并消除碎片。Go 不整理，这意味着它永远不需要更新指向已移动对象的指针（更简单的写屏障，无需读屏障以保证正确性）。Go 通过大小类分配器（size-class allocator）来补偿。这是经典的 Wilson 权衡：拷贝和整理收集器以内存开销和指针更新成本换取分配速度和碎片消除。
ZGC 的有色指针是 Wilson 指针标记 (pointer-tagging) 思想的现代实现。 Wilson 提到过在指针中使用位来存储 GC 元数据。ZGC 将此进一步发展，将标记状态、重映射状态和终结状态直接嵌入 64 位指针。在每次指针加载时检查这些位的加载屏障是 ZGC 为亚毫秒级停顿支付的代价。
基本问题从未改变。 从 roots 开始追踪，标记存活内容，回收其余部分。自 1960 年以来的所有发展都是对 McCarthy 原始洞察的工程改进。
你的“停顿”时刻
GC 的艺术在于平衡。在你的开发生涯中，是否遇到过因为 GC 停顿导致的生产事故？你是倾向于 Go 的极致低延迟，还是 Java G1GC 的高吞吐？
欢迎在评论区分享你的调优经历或吐槽！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-04-06 08:27:24
本文永久链接 – https://tonybai.com/2026/04/06/how-to-write-unmaintainable-code
大家好，我是Tony Bai。
在这个由 Claude、GPT、Gemini等大模型定义的 2026 年，我们似乎已经习惯了 AI 那种近乎“洁癖”的编码风格：优雅的接口设计、滴水不漏的错误处理、以及永远对齐的工整格式。
AI 正在用它那冰冷的、毫无感情的逻辑，将软件工程推向一个前所未有的标准化时代。
但就在前几天，我在一个尘封的互联网角落里，挖出了一本写于 1999 年的上古奇文——《How To Write Unmaintainable Code》（如何编写不可维护的代码）。
这篇文章的作者 Roedy Green，怀着一种极其黑色幽默的极客精神，手把手教导当年的 Java 程序员们，如何写出能让“接盘侠”当场崩溃、从而保证自己“终身就业”的屎山代码。
当我用 AI 时代的眼光，去重新审视这本 27 年前的“反向圣经”时，我感到既荒谬又亲切。它就像一面镜子，照出了在没有 gofmt、没有 AI、没有 Claude Code 的“古法编程”时代，我们曾如何野蛮生长，以及 Go 语言在设计之初，就已经用多么前瞻性的眼光，封印了那些曾经肆虐一时的“魔鬼”。
今天，就让我们开启一场技术考古之旅，用现代 Go 语言，来“复刻”一下这些差点失传的“防御性”编程之术。
Roedy Green 在开篇就点明了核心：维护者看代码，就像通过一个卫生纸筒的中心在看世界，视野极其狭窄。
你的任务，就是让他永远无法拼凑出完整的画面。
go
// 古法复刻
var l int64 = 11 // 这是 11 还是 1l？
var speed int = O1 // 这是 O1 还是 01？
go
// 古法复刻
var swimmer, swimner string // 99% 的 Code Review 都会看走眼
var hashTable, HashTable *map[string]int
go
// 古法复刻
func GetUserAuth(...) {}
func GetUsrAuthorization(...) {}
var athnClient *Client
go
// 古法复刻
i++ // i plus 1
滥用全局变量：永远不要使用局部变量，把一切都提升为包级变量，让并发的 Goroutine 们去为了争夺它而自相残杀。
// 古法复刻
var tempResult string // 提升为包级变量
func HandleRequestA() {
tempResult = "result_from_A"
// ...
}
func HandleRequestB() {
tempResult = "result_from_B"
// ...
}
// 当这两个函数并发执行时，一场血案即将发生。
当然原文中，Roedy Green的“骚操作”不止这些。
但其中的一些“防御”手段对今天的Go语言来说，并不生效。
你会发现 Go 语言在设计之初，就已经对这些“手段”进行了“免疫”，比如：
当然，Go 也不是万能的。很多源自 Java/C++ 时代的“高级骚操作”，在 Go 里依然可以“继续存在”。
go
// 古法复刻：这个函数名和类型名完全一样，但它不是构造函数！
type User struct{ name string }
func User(name string) { /* ... do something evil */ }
go
// 古法复刻
if len(users) > 99 { // 这里是 > 99
// ...
}
for i := 0; i < 100; i++ { // 这里是 < 100
// ...
}
go
// 古法复刻
func Process(input interface{}) {
switch v := input.(type) {
case string: // 处理字符串
case int: // 处理整数，但逻辑和 string 完全不同
// ...
}
}重温这本 27 年前的“反向圣经”，在今天这个 AI 编程时代，显得格外有意义。
AI 的出现，正在把“编写可维护代码”的门槛，拉到前所未有的低点。一个初级程序员，在 AI 的辅助下，也能写出格式工整、变量命名规范的代码。
但这是否意味着“屎山”将成为历史？
恰恰相反。AI 在解放我们生产力的同时，也正在“批量化”和“隐蔽化”地制造着“新时代的屎山”。AI 可能会生成一段逻辑上看似完美，但在高并发下会引发严重数据竞争的代码；它也可能会为了实现一个简单功能，引入一个庞大且带有安全漏洞的第三方库。
这本古老的指南提醒我们：技术的进步可以消灭“语法层面”的丑陋，但永远无法替代人类工程师在“架构层面”的审美与抉择。
在 AI 时代，我们不再需要像 Roedy Green 那样，靠着“加密代码”来保住饭碗。但我们比以往任何时候，都更需要理解那些“不可维护代码”背后的设计缺陷，从而在 Code Review 中，扮演好 AI 的“最终质检员”角色。
代码的整洁与混乱，终究是一场关于“责任心”的博弈。无论时代如何变迁，这，或许是软件工程永恒的真理。
当然，如果你真的想了解古法编程时代的更多“骚操作”，可以看看Roedy Green的原文：https://www.doc.ic.ac.uk/%7Esusan/475/unmain.html
今日互动探讨：
在你见过的 Go 项目中，遇到过哪些让你拍案叫绝、或者让你想“提刀来见”的“屎山代码”骚操作？
欢迎在评论区分享你的“开眼”经历！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-04-04 08:45:30
本文永久链接 – https://tonybai.com/2026/04/04/the-death-of-coding-joy-in-the-age-of-ai-agents
大家好，我是Tony Bai。
过去的两年，我们见证了 AI 编程工具从“玩具”到“神器”的进化。从 Copilot 的代码补全，到 Claude Code 的“一句话建站”，再到各种Coding Agent 的“自主开发”，我们写代码的效率被史无前例地拉满了。
但在这场效率的狂欢之下，一股难以言喻的“失落感”和“空虚感”，正在资深程序员群体中悄然蔓延。
就在几天前，Reddit 的 r/webdev 社区（一个拥有 66 万开发者的顶级论坛）上，一位拥有 20 年经验的资深后端工程师发了一篇帖子，标题极其刺眼：《AI has sucked all the fun out of programming》（AI 榨干了编程所有的乐趣）。
他写道：
“我曾对自己解决难题、深挖源码的能力无比自豪。但自从 Claude Code 变得越来越强，我感觉自己不再是一个程序员，更像是一个项目经理，每天管理着一个叫 Claude Code 的中高级外包。我交付功能的速度比以往任何时候都快，但内心却无比空虚。这些没有灵魂的特性，我无法再把它们看作是我的创造。”
“AI 让我变得极度懒惰，它彻底摧毁了我作为一个优秀工程师、甚至一个人类的价值。我希望它从未被发明过。”
这篇充满“怨气”的帖子，像一块巨石砸入了平静的湖面，瞬间引爆了整个社区。短短一天，帖子收获了 1500+ 的高赞和近 400 条评论。无数开发者涌入评论区，分享着自己在 AI 时代相似的困惑、挣扎与幻灭。
今天，我们就来扒开这场顶级社区的“赛博哀悼会”，看看当 AI 剥夺了编程最后的“手艺活”时，我们这些“数字工匠”，到底失去了什么？
在评论区，点赞最高的一条回复，只用了一句话，就说出了所有人的心声：
“是的，是的，是的。而且，审查那些由 AI 生成的、过度工程化的垃圾 PR，简直让人精疲力竭。”
这精准地概括了资深程序员们失落感的第一个根源：身份的降维。
在没有 AI 的时代，我们是“创造者”。我们享受的是从零开始，将复杂的业务逻辑，通过一行行精巧的代码，构建成一个优雅系统的过程。那种“庖丁解牛”般的掌控感和心流体验，是支撑我们熬过无数个加班夜的精神支柱。
而现在呢？
AI 成了那个大刀阔斧的“创造者”，它可以在几分钟内生成 10 个文件、成千上万行代码。而我们，这些曾经的“建筑师”，被迫降级成了一个卑微的“代码审查员（Code Reviewer）”。
我们的日常工作，不再是“如何巧妙地设计一个接口”，而是“如何在这堆由 AI 生成的、看似完美却隐藏着无数暗雷的代码里，找出那个该死的 Bug”。
一位开发者形容这种感觉就像“吃屎”：
“重构一小段代码，就像在菜里加点盐，很有趣。但如果让你 9 点到 5 点都在重构 AI 生成的屎山，那就完全是另一回事了。”
除了身份的降维，更让开发者们感到恐惧的，是“学习感的丧失”。
一位只有 2 年经验的前端开发者的评论获得了 123 个高赞：
“AI 确实让我变快了。但有时我感觉，我跳过了那些本该挣扎和学习的部分。而正是那些挣扎，才让知识真正刻进我的脑子里。”
这说出了一个残酷的真相：人类的学习，本质上是一个伴随着痛苦和摩擦的过程。
当你为了一个 Bug 熬了三个小时，翻遍了 Stack Overflow，最后在某个不起眼的角落找到解决方案时，你对这个 Bug 的理解是刻骨铭心的。
但现在，你只需要把报错信息扔给 Claude Code，它会在 3 秒钟内给你正确答案。
效率是提升了，但你的大脑也失去了构建深度知识模型（Mental Models）的机会。你成了知识的“搬运工”，而不是“内化者”。
更可怕的是，这种趋势正在从个人蔓延到团队，甚至威胁到新人的成长路径。
评论区的一位开发者也分享了他的遭遇：
“我们是做嵌入式开发的，AI 很多时候根本不懂底层。但我们的经理对 AI 产生了宗教般的狂热，他强迫我们必须用 AI。如果我们不用，他就会 visibly upset（肉眼可见地不爽）；如果我们用了，然后报告 AI 出了问题，他会立刻假定是我们用错了，而不是 AI 的问题。”
这种来自管理层的“AI 迷信”，正在让那些真正懂技术的专家感到心寒。当你的老板拿着 ChatGPT 的一段胡言乱语来质疑你的专业判断时，技术尊严的丧失，远比失去乐趣更令人痛苦。
当然，也并非所有人都对 AI 感到悲观。评论区同样出现了鲜明的“效率派”阵营。
一位拥有 27 年经验的资深开发者表达了截然不同的看法：
“我反而觉得 AI 增强了我的能力。我依然负责掌控项目的整体架构，AI 只是帮我处理那些烦人的、重复的体力活。这就像我有了一个能完美听懂我话的初级开发人员，而且他永远不会抱怨。”
另一位开发者则将这种转变描述为角色的升维：
“乐趣转移了，但没有消失。我们团队的人类现在负责所有的架构决策，AI 负责具体的实现。创造性的工作依然存在——它从‘如何写好这个函数’，变成了‘如何设计好这个系统’。我们从‘砖瓦工’，变成了‘建筑师’。”
这两种截然不同的声音，揭示了 AI 时代开发者社区正在经历的一场剧烈的身份分化：
这两种观点没有对错，它仅仅反映了不同性格的开发者，在面对一场史无前例的生产关系变革时，所产生的自然分化。
在这场关于“乐趣与灵魂”的大讨论中，我们依然能找到一些极具建设性的生存法则。
第一，坚决捍卫“人类最终解释权”。
AI 可以生成，但你必须成为那个拥有“一票否决权”的最终审计者。正如一位开发者所言：
“我正在无视所有关于‘再不拥抱 AI 就会被淘汰’的末日预言。我只把它当成一个强化版的搜索引擎。如果未来真的只需要一批不懂底层原理的‘提示词操作员’，那我的工作反正也变得毫无意义了。但如果未来依然需要懂底层的人，那我的处境绝对比那些‘氛围编码’了好几年的人强得多。”
第二，主动创造“无 AI 日（Zero AI Day）”。
另外一位开发者的建议获得了很多人的认同：
“为了对抗这种侵蚀，我每周会选定一天作为我的‘无 AI 日’。在那一天，我禁止自己使用任何 AI 工具。这种感觉非常自由。”
这就像健身中的“欺骗餐”，它能让你重新找回对代码最原始的“手感”。
第三，把 AI 当作“副驾驶”，而不是“自动驾驶”。
真正的老司机，绝不会在高速上双手离开方向盘。他们会利用 AI 去处理那些最耗时、最没有创造性的部分：写单元测试、生成 OpenAPI 文档、转换数据格式。
而在核心的业务逻辑和架构设计上，亲手去写，去感受系统的“摩擦力（Friction）”，去构建你脑海中那张独一无二的架构蓝图。
AI 的出现，极大地满足了我们对“即时反馈”的多巴胺式快感：敲一句话，代码就出来了。
但真正的编程乐趣，那种来自于深度思考、解决难题后获得的、持久而宁静的成就感，属于“内啡肽”。
AI 正在用廉价的多巴胺，稀释我们获取内啡肽的能力。
我们不必为此感到绝望。正如工业革命没有消灭所有手工艺人，反而催生了更昂贵的“高级定制”一样。
当 AI 能够批量生产千篇一律的“预制菜”代码时，那些依然能够亲手雕琢出艺术品级架构的“米其林大厨”，其价值将不降反升。
问题的关键在于，在这场大浪淘沙中，你，是选择成为流水线上一颗随时可被替换的螺丝钉，还是那个手握最终菜谱的顶级大厨？
今日互动探讨：
在使用 AI 编程后，你的“编程乐趣”是增加了还是减少了？你觉得 AI 帮你完成的最有价值和最没有价值的工作分别是什么？
欢迎在评论区分享你的真实感受！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-04-03 08:32:35
本文永久链接 – https://tonybai.com/2026/04/03/agentic-api-in-action
大家好，我是Tony Bai。
在过去的十几年里，如果你问任何一位后端工程师：“我们应该如何设计 API？”得到的答案几乎是统一的：RESTful。
我们将世界抽象为一个个“资源（Resources）”，用名词来命名 URI（比如 /users, /orders），用 HTTP 动词（GET, POST, PUT, DELETE）来表达对这些资源的操作。这套基于 CRUD（创建、读取、更新、删除）的法则，优雅地统治了移动互联网和微服务时代。
然而，时代变了。
当我们步入 AI 时代，尤其是当各种大语言模型（LLM）驱动的智能体（AI Agent）开始接管我们的软件系统时，一个尖锐的矛盾浮出水面：这群“硅基同事”在面对我们精心设计的 REST API 时，表现得像个无所适从的笨蛋。
今天，作为本专栏的开篇，我想和你探讨一个极其现实的工程问题：为什么在 AI 时代，统治后端十年的 REST 架构正在失效？我们又该如何为 AI 智能体设计下一代接口——Agentic API？
为了理解 REST 的局限性，我们不妨先来做个角色互换。
假设你现在不是一个人类工程师，而是一个被赋予了任务的 AI Agent。你的主人对你说：“帮我把昨天那个发错的订单取消掉，并给客户退款。”
作为 Agent，你拥有一个极其强大的大脑（比如 GPT-5.x 或 DeepSeek-V3.x），并且你被授权访问公司内部的订单系统 API。你兴冲冲地查看了该系统的 Swagger 文档，看到了以下几个端点：
这时候，你的“认知障碍”出现了。
你要“取消订单”，但在 REST 的世界里，并没有一个叫“取消”的操作。
你应该调用 DELETE /orders/{id} 吗？如果你真的这么做了，你可能就把这条订单的物理记录从数据库里抹掉了，这在真实的电商系统中是灾难性的（通常我们需要软删除或者状态流转）。
还是说，你应该调用 PUT /orders/{id}，并在 JSON Payload 里传一个 {“status”: “CANCELLED”}？这听起来合理一些，但如果你传的是 {“status”: “DELETED”} 呢？API 会报错吗？
REST API 强迫调用者去猜测后端的业务逻辑映射。 对于人类开发者，我们可以通过阅读厚厚的 API 接入文档，或者直接去问写这个接口的同事来澄清。但对于 AI Agent，它只能基于常识去“猜”。当 AI 开始猜你的系统设计时，就是灾难的开始。
更糟糕的是，主人的任务是“取消订单并退款”。
在 REST 架构下，订单资源（/orders）和退款资源（/refunds）通常是分离的。AI Agent 必须自己完成以下编排：
如果步骤 1 成功了，但步骤 2 因为网络超时失败了怎么办？AI Agent 需要具备复杂的错误恢复机制和分布式事务处理能力（比如发起撤销操作）。我们把极其复杂的系统状态一致性问题，推给了客户端（AI）。
为了让 AI 能够完成上述操作，你需要给它分配什么样的权限？
在传统的 OAuth 2.0 体系中，你可能不得不给它 order:write 和 refund:write 权限。这意味着，这个 AI Agent 不仅能取消订单，它还能修改订单金额，甚至能随意发起退款！
REST API 以“资源”为粒度划分权限，这对于非确定性的 AI 来说，权限敞口太大了。 我们真正想给 AI 的权限是“仅限取消特定状态的订单”，但这在传统的 REST 模型中极难优雅地表达。
面对上述痛点，业界最近非常流行一种解决方案：让 AI 使用工具（Tool Calling / Function Calling）。
比如 Anthropic 推出的 MCP（Model Context Protocol）协议，它的核心思想是：在 AI 和系统之间架设一个中间件（MCP Server），将系统的能力包装成一个个具体的 Tool（工具）暴露给 AI。
这确实缓解了部分问题，AI 可以直接调用名为 cancel_order_and_refund 的工具了。但请注意，这治标不治本。
这相当于我们在后端依然写着糟糕的、极难编排的 REST API，然后派人写了一堆中间层胶水代码（Glue Code）来适配 AI。随着系统变得复杂，维护这些“胶水工具”的成本将呈指数级上升，状态同步和权限控制的难题依然存在。
我们真正需要的，是一场后端架构范式的革命：从源头上设计对 AI 友好的 API。
这就是本微专栏要向你隆重介绍的 Agentic API 理念。
Agentic API 的核心思想是：放弃将世界强行扭曲为“资源（名词）”，回归人类和 AI 最自然的交流方式——“任务与意图（动词）”。
我们来看一个对比。
传统 REST API 的思维模式：
“这里有一个 Order 资源。你可以对它执行 POST, GET, PUT, DELETE。”
Agentic API 的思维模式：
“这里有一个业务系统。你可以执行 CANCEL（取消订单）, REFUND（发起退款）, NOTIFY（发送通知）等明确的任务。”
我们用一张简单的时序图来对比一下这两种模式下，AI Agent 完成“取消并退款”任务的复杂度差异：
在 Agentic API 模式下：
光说不练假把式。接下来，我们将用 Go 语言，从零开始将一个传统的 REST 接口改造为 Agentic API。
假设我们正在开发一个博客系统，我们需要一个接口让 AI 帮我们“总结一篇文章的核心观点”。
请确保你已安装 Go 1.21 或以上版本。我们将使用标准库 net/http 来保持代码最简。
创建一个新目录并初始化模块：
mkdir agentic-api-demo
cd agentic-api-demo
go mod init agentic-demo
touch main.go
在传统的 CRUD 思维下，很多开发者可能会这么设计：
让客户端发送一个 POST /documents/{id}/summary 请求，或者使用一个万能的 PATCH /documents/{id}，带上一个 action=summarize 的字段。
这虽然能工作，但语义不够清晰，扩展性极差（如果明天需要翻译、提取关键字呢？）。
在 Agentic API 的设计中，我们提倡使用明确的动词驱动路由。针对这种数据处理类的任务，我们可以定义一个 COMPUTE 或 ANALYZE 大类。
让我们在 main.go 中写下这段优雅的代码：
// ch01/agentic-api-demo/main.go
package main
import (
"encoding/json"
"fmt"
"log"
"net/http"
"strings"
)
// AgenticRequest 代表了 AI 智能体发来的标准任务请求
type AgenticRequest struct {
// 明确的意图动作
Action string json:"action"
// 动作的目标上下文 (例如文档ID)
ContextID string json:"context_id"
// 动作需要的特定参数
Parameters map[string]interface{} json:"parameters,omitempty"
}
// AgenticResponse 代表了返回给 AI 的标准结构化响应
type AgenticResponse struct {
Status string json:"status" // SUCCESS, FAILED, REQUIRE_CONFIRM
Result interface{} json:"result,omitempty"
Message string json:"message,omitempty"
}
func main() {
// 定义一个面向动作的路由前缀
http.HandleFunc("/api/v1/actions", actionHandler)
fmt.Println("Agentic API Server started on :8080")
log.Fatal(http.ListenAndServe(":8080", nil))
}
// actionHandler 充当了“任务调度中心”
func actionHandler(w http.ResponseWriter, r *http.Request) {
if r.Method != http.MethodPost {
http.Error(w, "Only POST is allowed for actions", http.StatusMethodNotAllowed)
return
}
var req AgenticRequest
if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
sendResponse(w, http.StatusBadRequest, "FAILED", nil, "Invalid JSON payload")
return
}
// 核心：基于 Action (动词) 进行路由分发，而不是基于资源名词
switch strings.ToUpper(req.Action) {
case "SUMMARIZE":
handleSummarize(w, req)
case "TRANSLATE":
// handleTranslate(w, req)
sendResponse(w, http.StatusNotImplemented, "FAILED", nil, "Action TRANSLATE not implemented yet")
default:
sendResponse(w, http.StatusBadRequest, "FAILED", nil, fmt.Sprintf("Unknown action: %s", req.Action))
}
}
// handleSummarize 处理具体的总结任务
func handleSummarize(w http.ResponseWriter, req AgenticRequest) {
docID := req.ContextID
if docID == "" {
sendResponse(w, http.StatusBadRequest, "FAILED", nil, "context_id (Document ID) is required")
return
}
// 解析可选参数 (Agentic API 应该允许 AI 传入控制参数)
maxLength := 100 // 默认值
if ml, ok := req.Parameters["max_length"].(float64); ok {
maxLength = int(ml)
}
// 模拟从数据库获取文档并进行总结的复杂逻辑
log.Printf("Executing SUMMARIZE for doc: %s, max length: %d\n", docID, maxLength)
// 模拟生成的摘要
mockSummary := fmt.Sprintf("这是关于文档 %s 的核心总结，长度被限制在 %d 字以内：Agentic API 是未来的趋势。", docID, maxLength)
// 返回标准化响应
sendResponse(w, http.StatusOK, "SUCCESS", mockSummary, "Document summarized successfully")
}
// 统一的响应封装助手
func sendResponse(w http.ResponseWriter, statusCode int, status string, result interface{}, message string) {
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(statusCode)
resp := AgenticResponse{
Status: status,
Result: result,
Message: message,
}
json.NewEncoder(w).Encode(resp)
}
在终端运行该代码：
go run main.go
现在，假设你是一个 AI Agent，你决定执行“总结文章”的任务，你可以构造如下清晰的 Payload 发送给后端：
curl -X POST http://localhost:8080/api/v1/actions \
-H "Content-Type: application/json" \
-d '{
"action": "SUMMARIZE",
"context_id": "doc_9527",
"parameters": {
"max_length": 50
}
}'
你会得到一个标准化的、极易解析的响应：
{
"status": "SUCCESS",
"result": "这是关于文档 doc_9527 的核心总结，长度被限制在 50 字以内：Agentic API 是未来的趋势。",
"message": "Document summarized successfully"
}
看出区别了吗？
我们建立了一个统一的 /actions 门户。AI 只需要指明它想做什么（Action: SUMMARIZE），针对什么目标（ContextID: doc_9527），以及有何要求（Parameters）。
后端完全掌控了路由分发、参数校验和复杂的业务实现。如果你明天需要增加一个“翻译”功能，对于 AI 来说，只是换了一个动词（TRANSLATE），它的交互模式（Schema）没有任何改变。这种一致性极大地降低了 AI 的试错成本和代码生成复杂度。
刚才的实战只是开胃菜。要让你的整个微服务集群、成百上千个接口都变成“Agent-Ready（AI 就绪）”，我们需要一套完整的架构方法论。
这就引出了我们这个《Agentic API 实战：为 AI 智能体设计下一代接口》微专栏，以及后续的安排。
在接下来的 5 讲中，我将摒弃那些空洞的 AI 概念，从一名后端架构师的视角出发，带你一步步把这套理念落地为真实的生产级能力。所有核心模式都会配备详实的 Go 语言可运行代码。
以下是我们接下来的“作战路线图”：
这是一次从思维方式到工程实现的全面升级。如果你准备好了迎接 AI 带来的自动化红利，并且希望成为团队里那个“最懂如何让机器调接口”的架构师，那么，请扫描下方二维码，紧跟我的步伐。
今天，我们站在了一个新时代的起点。
这仅仅是冰山一角。在接下来的专栏中，我们将深入探讨 Agentic API 的骨架：六大核心 ACTION 分类法。我们将学习如何让 AI 自动“发现”你的系统能力，如何通过扩展 OpenAPI 规范生成完美的智能体说明书，以及如何设计让 AI 执行复杂连锁任务的“沙盒测试模式”。
世界正在不可逆转地走向自动化，懂 AI 调用的 API 架构师，将成为下个十年最稀缺的资源。我们下一讲见！
本讲涉及的示例代码和脚本可以在这里下载。
在你的日常开发中，有没有遇到过一个传统的 REST API（比如一个修改用户状态的 PUT 接口），它的内部逻辑其实非常复杂（包含了发邮件、写审计日志、调起其他微服务等操作）？
如果让你用 Agentic API 的思维（动词驱动）重新设计这个接口的访问方式，你会怎么命名这个 Action？它的 Payload 结构会是什么样的？
欢迎在评论区留下你的思考和设计，我会和你一起讨论。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-04-02 08:08:43
本文永久链接 – https://tonybai.com/2026/04/02/2026-programming-language-saturation-rankings-go-rust-winners
大家好，我是Tony Bai。
在这个技术浪潮汹涌、AI 随时可能掀翻牌桌的时代，每一个程序员心中都悬着一个终极问题：
“我现在的技术栈，还能吃几年饭？”
我们每天都在焦虑地刷着各种技术文章，试图从 Google、Anthropic、OpenAI、Nvidia等的风向中，窥探下一个技术红利期。但这些信息往往零散、矛盾，甚至充满了各种培训机构的“幸存者偏差”。
就在半个多月前，X 平台上的一位技术博主 Mojisola Alegbe，基于 Stack Overflow、GitHub Trends、JetBrains 等多方数据，整理并发布了一份极其残酷的私房版《2026 编程语言“饱和度”榜单》。
这篇推文就像一颗深水炸弹，在短短几天内获得了 41.2 万的惊人阅读量。大批开发者涌入评论区，有人哀嚎，有人庆幸，有人愤怒，有人不屑。这张榜单之所以能引爆全网，因为它赤裸裸地揭示了我们这个行业最真实的“供需关系”和“内卷现状”。
今天，我们就来深度扒开这张榜单背后的血泪与真相。看看你我手中的“锤子”，到底还能敲几年钉子。
让我们先深吸一口气，看看这份令人心跳加速的榜单：
看完这张图，我猜很多人的第一反应是：
但如果事情真的这么简单，那我们这个行业也未免太无趣了。这张榜单真正有价值的地方，在于它炸出了评论区里无数资深架构师和一线开发者的“人间清醒”。
在这张榜单的评论区，你可以看到整个技术圈最真实的生态缩影。
阵营一：饱和焦虑派
“完了，我刚想学编程，这可怎么办？”
“怪不得现在工作这么难找……”
阵营二：不屑一顾派
“语言只是工具，解决问题才是关键。”
“这种指标毫无意义。”
阵营三：人间清醒派（重点看这里！）
这部分评论，往往来自那些穿越了数个技术周期的老炮。他们的观点，破具含金量。
一位开发者一针见血地指出：
“语言的饱和度是个误导性指标。真正的问题不是有多少开发者懂它，而是有多少开发者能用它构建出真正有价值的系统。”
另一位开发者则更加直接：
“饱和度百分比毫无意义。重要的是：你能交付吗（Can you ship）？我只看三个信号：1. 真实的生产环境部署（而不是教程）；2. 系统设计的深度（而不只是 CRUD）；3. 在压力下调试复杂问题的能力。JavaScript 饱和度 66%？那又怎样，其中 90% 的人连一个可扩展的架构都设计不出来。”
而一位博主，更是给出了顶级玩家的“搞钱思路”：
“聪明的开发者从不追逐‘流行’的语言，他们追逐的是‘高价值’的行业
– Python → AI
– C++ → 高性能系统（游戏、金融）
– Rust → 安全基础设施（区块链、操作系统）
– Go → 云平台（K8s、Docker）
追逐金钱，而不是追逐炒作（Follow the money, not the hype）。”
扒开社区的口水战，我们可以总结出三条极其宝贵的“反内卷”生存法则。
第一条：停止在“语言层”的低水平竞争
如果你是一个 Python 开发者，你的核心竞争力绝对不是“比别人多会几个 itertools 的函数”。
评论区里的一条建议非常中肯：
“不要只学 Python 的语法。去学它底层的 C++ 和 CUDA。这才是 2026 年 AI 热潮中真正值钱的地方。”
同样的道理，如果你是一个前端开发者，让你在面试中脱颖而出的，绝不是多会几个 CSS 动画技巧，而是你对 V8 引擎的内存管理、对大规模前端项目的架构设计、对 WebAssembly 的底层原理的深刻理解。
饱和的永远是“表层应用”，而“底层原理”的护城河，深不见底。
第二条：将你的技术栈，锚定在高价值的“产业赛道”
你选择的语言，决定了你的“工具”；而你选择的行业，决定了你“工具”的价值。
如果你用 Go，但每天只是在写一些简单的 CRUD 业务，那你和用 PHP 的同行并没有本质区别。
但如果你用 Go，去深耕 Kubernetes Operator 开发、去搞 Service Mesh、去做 eBPF 的底层监控，那你将进入一个截然不同的“高价值稀缺区”。
对于大多数开发者来说，最好的策略不是去学一门全新的、不饱和的语言（比如 Zig 或 OCaml），而是在你现有的、最熟悉的语言生态里，找到那个与“高利润、高壁垒”行业结合最紧密的纵深方向，然后一头扎进去。
第三条：从“语言专家”进化为“系统架构师”
评论区里，有一个非常有趣的现象：初级开发者在讨论“哪个语言好”，而资深开发者在讨论“如何交付（Ship）”。
当一个系统变得复杂时，瓶颈往往早已不在于某个语言的语法特性，而在于：
这些“跨语言”的系统设计能力，才是拉开普通程序员和架构师之间收入差距的根本原因。
语言的红利期是短暂的，而架构的复利是终身的。
这张“饱和度”榜单，与其说是一份“死亡通知单”，不如说是一张“体检报告”。它提醒我们，如果你安于现状，只停留在语言的表层舒适区，那么无论你现在用的是 Go 还是 Python，你都随时可能被更便宜、更年轻的开发者所取代。别忘了还有不断“蚕食”初级甚至中高级程序员工作的AI！
在这个充满不确定性的时代，真正的安全感，来源于：
不要再为“哪个语言是宇宙第一”而进行无意义的口水战了。
你的价值，从来不是由你用什么语言决定的，而是由你能用这门语言，解决多大、多复杂、多有价值的问题决定的。
资料链接：https://x.com/yehhmisi/status/2031715243622015239
今日互动探讨：
看完这份榜单，你对自己目前的技术栈感到了焦虑，还是庆幸？在你看来，一个语言的“饱和”是危机，还是意味着更成熟的生态和机会？
欢迎在评论区分享你的看法！
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？
继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！
我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。
目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
