Go 1.25绿茶GC实测：40%性能提升为何有人用不上

同一周，两个团队同时开启了同一个实验开关。一个默默回滚，另一个把35%的GC CPU降幅写进了生产配置。他们用的是同一版编译器，跑的是同一套运行时。差距在哪？

导读

Go 1.25的Green Tea GC（垃圾回收器）被官方标称"10-40% GC CPU降低"，但DoltHub和Tile38的实测结果天差地别。这不是测试误差，而是一条可以预判的规则——你的堆内存长什么样，决定了你能不能拿到这40%。

从对象到页面：Green Tea改了什么

Go 1.25之前，三色标记-清扫的遍历单位是单个对象。

工作线程从队列弹出一个指针，扫描该对象，把找到的指针塞回去，继续下一个。这套逻辑正确，但内存访问模式堪称灾难：跳到一个随机页，读64字节，再跳到另一个随机页，读32字节。在现代CPU上，这等于把大部分时间花在等内存上。Go团队测过，标记阶段35%以上的时间卡在主内存延迟。

Green Tea把工作单位换成了8 KiB页面（技术上是小对象span，小对象指≤512字节）。

当某个指针指向某页时，该页进队列。它会在队列里多待一会儿，等更多指向同一页的指针累积。工作线程取出页面时，一次性从左到右扫描页上所有可达对象，紧凑循环，预取器能猜中下一步。

元数据布局跟着变。每个小对象槽位带两个额外比特："已见"（有指针指向我）和"已扫描"。整页的"已见"比特打包进一两个机器字，这让AVX-512路径成为可能。运行时能用单条向量指令盘问整页的所有槽位。Go博客文档提到用VGF2P8AFFINEQB（伽罗瓦域仿射变换）把"已见"比特掩码展开成逐对象工作，只需几个周期。

实际翻译：在带AVX-512的CPU上（Ice Lake服务器、Sapphire Rapids、近期Zen），每页开销接近零。

官方基准数字（全部来自Go团队Green Tea博客及公告issue）：

• 标准基准套件GC CPU降低10-40%（无AVX-512）
• 带AVX-512时部分工作负载额外提升

两条时间线：DoltHub与Tile38的同一周

3月第二周：DoltHub的测试

DoltHub在Dolt数据库上跑oltp_read_write基准。Stock GC与Green Tea成绩：73.20 vs 73.36 tx/s。中位延迟相同，直方图肉眼重叠。Mark CPU在Green Tea下每周期都略高。他们回滚了。

同一周：Tile38的测试

Tile38团队记录GC CPU降低35%，吞吐和延迟改善写在上游issue。他们保持开关开启。

两个团队都跑Go生产服务，拉的是同一版编译器。差异在堆形状，而堆形状可以被预判。

预判规则：你的堆是什么形状

Green Tea的收益取决于一个变量：指针密度在同一页内的聚集程度。

Tile38是地理空间内存数据库。它的核心数据结构是R树、地理哈希、空间索引——大量同类型小对象，指针关系局部化。一个8 KiB页面上可能塞满R树节点，父节点指针、子节点指针、兄弟指针都在附近。Green Tea的页面队列能批量消化这些关联，预取器满载运行。

DoltHub的Dolt是版本化SQL数据库。存储引擎基于Prolly树，支持结构共享、版本回溯。这意味着任意两个版本可能共享大量底层块，指针分布天然碎片化。加上事务系统的混合负载，活跃对象在堆上呈稀疏分布。Green Tea的页面队列攒不够密度，反而多了元数据维护开销。

关键观察：Green Tea的"seen"比特机制需要同一页被多次指向才能摊平成本。如果堆的指针图是"星型"（少量大对象指向各处）或"随机网状"（指针跨页跳跃），页面队列退化成更慢的对象队列。

AVX-512：被误解的加速器

博客提到AVX-512时，很多读者以为这是性能主菜。实际是甜点。

向量指令加速的是"把比特掩码展开成工作列表"这一步。如果页面本身没攒够对象，掩码是空的，向量再快也无事可做。Go团队的40%上限来自标准基准套件，那些基准被特意设计成能触发页面聚集——不代表你的服务。

更隐蔽的点是：AVX-512在部分服务器CPU上会导致频率下降。如果你的GC压力本身不高，开向量路径可能净亏损。

40%为什么"真实又无用"

Go团队没撒谎。标准基准套件的10-40%是真实测量。但"标准基准"不等于"你的负载"。

这个区间的设计意图是：展示Green Tea在友好工作负载上的上限，同时诚实承认存在不友好的。问题在于，开发者读到"40%"时，默认自己属于上限那端。

实际决策框架：

• 高概率受益：内存缓存、索引服务、游戏状态机、任何以同构小对象为主的服务
• 高概率持平或受损：版本化存储、文档数据库、指针图高度动态化的系统
• 必须实测：混合负载、长期运行的服务（堆形状随时间漂移）

生产落地的正确姿势

Tile38的35%不是运气。他们的测试覆盖了GC CPU、吞吐、延迟、P99长尾，且观察了多轮GC周期。DoltHub的回滚同样专业——他们在Mark CPU微增时就止损，没等到吞吐崩塌。

建议的验证流程：

第一步：用GOEXPERIMENT=greenteagc编译，在影子流量或 staging 跑24小时以上。Go的GC日志输出GC CPU占比，对比基线。

第二步：检查runtime/metrics。关注/gc/cycles/automatic:gc-cycles的CPU时间，以及/gc/heap/objects的分布。

第三步：如果GC CPU降低但应用吞吐没涨，检查是否Mark阶段省了时间但Mutator（应用代码）被新布局的写屏障拖慢。Green Tea的写屏障比传统版本多一次原子操作。

第四步：长期观察。堆形状随数据生命周期变化，季度末的报表生成可能触发完全不同的指针模式。

这件事为什么重要

Green Tea是Go GC十年来的最大架构变动，但它不是免费午餐。它暴露了一个被长期忽视的事实：垃圾回收的性能不是由语言运行时单独决定，而是由你的数据结构设计共同决定。

Tile38和DoltHub的分化预示了未来趋势。随着AI推理服务、实时分析、边缘缓存的爆发，更多团队会发现自己站在Green Tea的分岔口——一边是35%的CPU省下来换更大模型或更低成本，另一边是白折腾一周。

Go团队选择用实验开关而非默认启用，是负责任的。但开关本身不提供答案，答案在你的堆内存里。

现在就去拉你的GC日志，看看对象们是怎么扎堆的。