Go 1.25 Green Tea GC 实战：别急着全量开启，先把 GC 成本测明白

Go 1.25 里我最建议后端团队认真评估的运行时变化，不是某个语法糖，而是实验性的 Green Tea GC。官方博客说得很直接：它是新的垃圾回收器实验，可以通过 GOEXPERIMENT=greenteagc 在构建时开启，目标是降低 GC 开销，尤其是改善对象扫描时的局部性。

但我不建议你看到“GC CPU 下降”就直接全量上线。GC 这种东西，收益和风险都和业务负载强相关。对象分配模式、堆大小、P99、容器 CPU limit、GOMEMLIMIT，全都可能影响结果。

这篇按我做线上性能改造的习惯来：先讲它大概解决什么，再给一套能落地的压测、观测和灰度流程。

Green Tea GC 解决的不是“要不要 GC”

Go 一直是并发标记清扫 GC，工程上已经很成熟。Green Tea 不是把 Go 改成另一种语言，也不是让你不用管分配了。它更像是对 GC 内部扫描和内存访问方式的一次重构，重点放在缓存局部性和批量处理上。

说人话就是：如果你的服务里有大量小对象、指针对象，GC 在扫描时会频繁访问内存。访问模式越分散，CPU cache 越不友好。Green Tea 想做的是让这部分工作更集中、更顺滑，从而减少 GC CPU 开销。

这也是为什么我说它适合“测”，不适合“猜”。有的服务短生命周期对象多，可能收益明显；有的服务主要卡在数据库、网络、锁竞争，换 GC 也救不了。

怎么开启

开启方式很简单，是构建期实验开关：

GOEXPERIMENT=greenteagc go build ./cmd/api

如果你们用 Docker 构建，可以把它放到构建阶段：

ENV GOEXPERIMENT=greenteagc
RUN go build -o /app/server ./cmd/server

注意，是构建期，不是运行时随手加个环境变量就生效。也就是说，你需要清楚地区分普通二进制和开启 Green Tea GC 的二进制，最好在版本号、镜像 tag、启动日志里都打出来。

先建基线，不然你不知道自己赢在哪

我见过很多性能优化最后讲不清收益，因为一开始没建基线。Green Tea GC 这种运行时变化，基线至少要包括这几类指标：

• CPU 总使用率和 GC CPU 占比。
• 请求 P50、P95、P99，尤其是尾延迟。
• 堆大小、GC 次数、每轮 GC 时间。
• 分配速率、alloc/op、B/op。
• 容器 CPU throttling 和内存水位。

本地可以先用 benchmark 看局部：

go test -run=^$ -bench=. -benchmem ./...
GOEXPERIMENT=greenteagc go test -run=^$ -bench=. -benchmem ./...

如果是服务型应用，单元 benchmark 只能做参考，真正要看压测。至少跑一轮同样请求模型、同样机器规格、同样并发、同样数据规模的对比。

别只看平均延迟

GC 改动最容易被平均值掩盖。一个接口平均延迟从 12ms 到 11ms，你可能觉得没意思；但如果 P99 从 180ms 到 120ms，线上体感就不一样了。

我会重点看三条线：

• GC 相关 CPU 有没有下降。
• P99 是否更稳，是否出现新的尖刺。
• 内存占用是否变化，尤其是 RSS 和堆目标大小。

如果 GC CPU 降了，但 P99 变差，先别高兴。可能是某些阶段的调度、缓存、内存峰值对你的负载不友好。实验性功能就要用实验的态度对待。

用 gctrace 看第一眼，但别停在 gctrace

本地或预发环境可以先打开：

GODEBUG=gctrace=1 ./server

它能让你快速看到 GC 频率、堆大小和暂停相关信息。但生产里我更建议用 metrics、pprof 和 tracing 结合看，别靠日志刷屏。

如果你的服务已经接了 Prometheus，可以关注 runtime 暴露的 GC、heap、pause、goroutine、CPU 相关指标；如果有连续 profiling，就直接看 runtime.gcBgMarkWorker、分配热点、对象保留路径有没有变化。

适合优先测试的服务

我会优先挑这些服务做试点：

• QPS 高、短生命周期对象多的 API 服务。
• JSON 编解码、协议转换、网关、聚合层。
• 历史 pprof 里 GC CPU 占比明显的服务。
• 容器 CPU limit 比较紧，偶尔被 GC 抢 CPU 的服务。
• 已经有压测脚本和回滚流程的内部服务。

不建议一开始拿核心交易链路全量试。先选可控服务，测出经验，再往重要链路推。

不适合优先折腾的场景

如果服务瓶颈明显在数据库、外部 RPC、锁竞争、慢 SQL、磁盘 IO，上来换 GC 大概率收益不大。你应该先把真正瓶颈解决掉。

还有一种情况也要谨慎：你们还没有稳定压测环境，没有清楚的监控基线，也没有快速回滚机制。这时候用实验性 GC，就是把不确定性直接带到线上。

灰度怎么做

我的建议是准备两个镜像：一个普通 Go 1.25 构建，一个 GOEXPERIMENT=greenteagc 构建。镜像 tag 要能一眼看出来，启动日志也打印 Go 版本和实验开关。

灰度顺序可以这样走：

• 预发压测：同等流量模型跑 30 分钟到 2 小时。
• 小流量：1% 或单实例观察，重点看 P99、错误率、RSS。
• 扩大到 5%-10%：和对照组并排看。
• 稳定后再扩大，不要一天内把所有服务都切完。
• 发现 P99 抖动、内存异常、CPU 反升，直接回滚普通镜像。

这里别怕保守。运行时实验的价值，是让你多一个工具，不是让你赌一把。

和 GOMEMLIMIT 一起看

现在很多 Go 服务跑在 K8s 里，除了 GC 本身，还会受到容器内存限制和 GOMEMLIMIT 影响。你不能只比较 GC 开关，还要确认两组实验的资源限制一致。

GOMEMLIMIT=768MiB ./server

如果一个版本因为内存目标不同导致 GC 频率不同，这个对比就不干净。线上评估时，把 Go 版本、构建参数、CPU limit、memory limit、GOMEMLIMIT、GOGC 都记录下来。

我的 review 清单

• 这个服务的 GC CPU 占比是否真的值得优化。
• 有没有普通构建和 Green Tea 构建的同条件压测结果。
• 是否比较了 P99、错误率、RSS、GC 次数，而不是只看平均延迟。
• 镜像 tag 和启动日志是否能区分实验版本。
• 是否有明确回滚方式。
• 是否记录了 Go 版本、GOEXPERIMENT、GOGC、GOMEMLIMIT 和容器资源限制。

最后说句实在话

Green Tea GC 很值得关注，但它不是“打开就赢”的魔法开关。它更像是 Go 运行时给高分配服务的一张新牌：你要先知道自己的牌局是什么，再决定要不要打出去。

我的建议很简单：别盲开，别恐惧。挑一个 GC 压力真实存在的服务，建基线、跑压测、小流量灰度。如果数据好看，就稳稳推进；如果数据一般，就先放回工具箱。工程里最好的优化，永远是能解释、能复现、能回滚的优化。