Go 1.25 引入实验性垃圾回收器 Green Tea，通过“以页为单位”扫描内存，显著降低 GC 停顿与 CPU 开销，部分场景性能提升高达 40%，有望成为 Go 1.26 默认 GC。
为什么你写的 Go 程序明明逻辑不复杂，但 CPU 却总是被“吃掉”一大块？不是业务逻辑太重，而是——垃圾回收（Garbage Collection，简称 GC）在偷偷拖后腿！
没错，就是那个默默帮你回收内存、防止内存泄漏的“幕后英雄”。但英雄也有累的时候。在高并发、大数据量、长时间运行的服务中，Go 的垃圾回收器甚至可能吃掉 20% 以上的 CPU 时间！这可不是小数目。
好消息来了！就在 2025 年 10 月发布的 Go 1.25 中，Go 团队悄悄塞进了一个“核弹级”新功能——Green Tea 垃圾回收器！名字听起来清新脱俗，实则威力惊人：在大量真实业务场景中，GC 的 CPU 开销直接下降 10% 到 40%！这意味着你的服务可以更省资源、响应更快、成本更低！
更关键的是，它已经在 Google 内部大规模生产环境中稳定运行，官方甚至计划在 Go 1.26 中直接把它设为默认 GC！今天，我们就用最接地气的方式，带你彻底搞懂这个“绿茶”到底有多香。
先认识一下这两位幕后大神。本文内容源自 Michael Knyszek 在 GopherCon 2025 大会上的演讲，由他与 Austin Clements 共同撰写。Michael 是 Go 运行时团队的核心成员，长期深耕垃圾回收与内存管理；Austin Clements 则是 Go GC 的资深架构师，曾主导多项关键优化。两人不仅是技术专家，更是实战派——Green Tea 不是纸上谈兵，而是经过 Google 超大规模系统验证的成果。
要理解 Green Tea 的突破，我们得先搞清楚 Go 原来的垃圾回收是怎么工作的。别担心，我们不用看代码，用一个“找人”的比喻就能说清楚。
想象你的程序里有一堆“对象”——比如用户信息、订单数据、缓存条目。这些对象之间通过“指针”互相连接，就像人与人之间的联系方式。Go 的垃圾回收器要做的，就是找出哪些对象还在被“使用”（比如被全局变量引用，或被其他活跃对象指向），哪些已经“没人要了”——这些没人要的对象，就可以安全地回收掉，腾出内存。
这个过程，叫“追踪式垃圾回收”（Tracing GC），具体实现是经典的“标记-清除”（Mark-Sweep）算法。
标记阶段：从“根”出发（比如 main 函数里的变量、全局变量），像洪水一样顺着指针一路找下去，把所有能碰到的对象都“标记”为“还在用”。
清除阶段：遍历整个堆内存，把没被标记的对象统统清理掉，变成“空地”，供下次分配使用。
听起来很简单对吧？但问题就出在这个“洪水”上。
原来的 GC 就像一个快递员，手里拿着一张超长的送货单，上面写着一个个具体地址（对象）。他开着车（CPU）在城市（内存）里东奔西跑：送完 A 小区第 3 栋 502，马上又要去 B 商圈地下车库 B2-17，接着又跳到 C 工业园 8 号厂房……路线极其随机，毫无规律。
现代 CPU 可不是傻跑的机器。它有“缓存”（Cache），就像快递员的后备箱——如果下一站就在附近，东西直接从后备箱拿，飞快；但如果每次都要回总部仓库（主内存）取货，那速度就慢到哭。更糟的是，CPU 还会“预判”你下一步要干嘛，提前加载数据。但这种随机跳跃的访问模式，让预判完全失效，缓存命中率暴跌。
结果就是：CPU 花大量时间“等内存”，性能被严重拖累。Go 团队分析发现，GC 时间里高达 90% 花在“标记”阶段，而这其中至少 35% 是卡在内存访问上！他们甚至称之为“微架构灾难”——不是算法错，而是和现代硬件“八字不合”。
雪上加霜的是，现在的服务器动不动就几十核，原来的 GC 虽然支持并行，但多个线程抢着操作同一个“送货单”（工作队列），又引发了新的竞争和延迟。
Green Tea 的核心思想，简单到令人发指：别盯着一个个对象了，直接按“页”来干活！
什么是“页”？你可以理解为内存的“街区”。Go 的堆内存被划分为一个个固定大小的页，每个页只存放相同大小的对象。Green Tea 的快递员不再看具体门牌号，而是直接说：“今天我要扫完整个 A 街区！”
具体怎么操作？
第一，工作队列里不再放“对象”，而是放“页”。只要某个页里有任何一个对象被引用了，整个页就被加入队列。
第二，扫描时，一次性把整个页里所有“待扫描”的对象全部处理完，按内存顺序从头扫到尾。
第三，为了实现这一点，Green Tea 给每个对象加了两个状态位：“seen”（是否被引用过）和“scanned”（是否已被扫描过）。通过这两个位的差值，就能知道当前页里哪些对象需要处理。
这样一来，快递员的路线就变了：他先在 A 街区把所有要送的包裹一次性送完，再去 B 街区扫一圈，再去 C 街区……路线变得连续、可预测。
这种改变带来的好处是颠覆性的。
首先，内存访问局部性大幅提升。CPU 缓存能高效命中，主内存访问次数锐减，彻底告别“微架构灾难”。
其次，工作队列变短了——原来可能有几万个对象排队，现在可能只有几百个页排队。线程竞争大幅减少，并行效率更高。
最炸裂的是，Green Tea 为“向量化加速”打开了大门！
现代 CPU 都有 SIMD 指令集，比如 AVX-512，能一次性处理 512 位数据。Green Tea 的页结构非常规整——每个页的对象大小一致，元数据（seen/scanned 位图）也整齐划一。Austin Clements 设计了一套精妙的向量扫描内核，利用 AVX-512 和新型位操作指令（如 VGF2P8AFFINEQB），能在几个 CPU 周期内完成整个页的指针提取！
原来的 GC 根本做不到这一点——对象大小不一、位置随机，向量指令无从下手。而 Green Tea 的规整结构，让硬件加速成为可能。据测试，开启向量化后，GC 开销还能再降 10%！
你可能会问：万一一个页里只有一个对象需要扫描，那不是白跑一趟，反而更慢？
Go 团队早就想到了。Green Tea 对“单对象页”做了特殊优化，避免无效开销。而且实测发现，哪怕一个页里只有 2% 的对象需要处理，整体性能依然优于传统 GC！因为连续访问带来的缓存收益，远超那点额外的判断成本。
当然，不是所有程序都能吃到全部红利。那些对象图极其稀疏、引用关系极度随机的 workload，收益可能有限。但绝大多数 Web 服务、微服务、数据库、缓存系统等，都能显著受益。
现在，你就可以尝鲜！在 Go 1.25 中，只需在编译时设置环境变量：
bash
GOEXPERIMENT=greenteagc go build
就能启用 Green Tea。注意，目前这个版本还不包含向量化加速，但基础性能提升已经非常可观。官方强烈建议大家在测试环境甚至生产环境试用，并反馈结果——无论是遇到问题，还是性能飙升，都请在 GitHub 上留言。
根据目前的数据，Go 团队计划在 Go 1.26 中将 Green Tea 设为默认 GC。届时，向量化加速也会正式上线，同时保留 GOEXPERIMENT=nogreenteagc 选项供你回退。
最后，别被“Green Tea”这个轻松的名字骗了。这项技术的背后，是 Go 团队长达七年的探索。早在 2018 年，类似的想法就已萌芽。中间经历了无数次失败、推翻、重构。直到 2024 年，Austin Clements 在日本咖啡馆里边喝抹茶边写原型，才真正验证了核心思路的可行性。2025 年，Michael Knyszek 将其工程化、产品化，最终落地。
这不是一个人的灵光一现，而是一群顶尖工程师在内存管理这片“无人区”里，用耐心、协作和极致的工程精神，硬生生蹚出的一条新路。
所以，下次你的 Go 服务突然变快了，别忘了感谢这杯“绿茶”——它不仅清新，还真的能提神醒脑，让你的程序跑得更快、更稳、更省！