Go 1.26 Green Tea GC 默认启用后如何观察内存变化

Go 1.26 把 Green Tea GC 从实验特性改成默认启用，但“GC 开关变了”不等于“进程 RSS 一定下降”。要观察真实变化，应该固定源码、输入规模和机器，分别记录堆指标、GC 周期、暂停时间与业务尾延迟；只有这些数据在相同负载下稳定改善，才适合继续灰度。

最实用的做法是先用 runtime.ReadMemStats 记录 HeapAlloc、HeapInuse、NumGC 和 PauseTotalNs，再用 GODEBUG=gctrace=1 看周期行为，最后用 GOEXPERIMENT=nogreenteagc 重建一个对照二进制。RSS 只能作为结果指标，不能单独证明 GC 变好。

先确认 Green Tea GC 的默认状态

Go 官方 1.26 发布说明给出的边界很清楚：Green Tea GC 过去在 Go 1.25 作为实验能力提供，Go 1.26 起默认启用；如果因为性能或行为问题需要停用，构建时设置 GOEXPERIMENT=nogreenteagc。它是构建级选择，不是让程序启动后临时切换的运行时参数。

因此第一步不要先盯着某一次 RSS。把编译器版本、操作系统、CPU 架构、GOMAXPROCS、输入规模和提交号写进实验记录。相同源码在不同 Go 小版本或不同 CPU 上，扫描路径和调度噪声都可能不同。

用固定负载采集堆与 GC 指标

下面的示例故意让每轮产生短命对象，再保留一部分结果，便于观察分配和回收同时发生的场景：

package main

import (
    "fmt"
    "runtime"
    "time"
)

func main() {
    var keep [][]byte
    for round := 1; round 

这组数据至少要运行三次，比较中位数而不是挑最好的一次。HeapAlloc 是当前堆中已分配对象的近似规模，HeapInuse 更接近运行时从堆取得的使用区间；NumGC 和 PauseTotalNs 则说明回收频率与累计暂停。它们不能直接等价为容器 RSS，后者还包含栈、运行时元数据、映射区和分配器保留页。

打开 gctrace 对照 GC 周期行为

如果还需要看每个 GC 周期的堆目标、标记工作和暂停信息，可以直接运行：

# 用同一份构建运行，保留每轮 GC 的文本记录，便于和 MemStats 对照。
GODEBUG=gctrace=1 ./mem-observe 2> gctrace-default.log

不要把一行 gctrace 当成完整结论。它适合回答“GC 是否更频繁”“每轮回收前后堆目标如何变化”“暂停是否出现异常尖峰”，而不是直接回答“服务应该分配多少内存”。若线上服务有 Prometheus 或 pprof，还应把实验指标与请求量、p95/p99 延迟、CPU 和 RSS 放在同一时间窗口里。

用 nogreenteagc 做一次构建级对照

对照构建必须保持源码、依赖、输入和机器不变，只改变 GC 实验开关：

# 构建不启用 Green Tea GC 的对照二进制；这是构建时选择，不是运行时环境变量。
GOEXPERIMENT=nogreenteagc go build -o mem-observe-classic .
GODEBUG=gctrace=1 ./mem-observe-classic 2> gctrace-classic.log

如果对照结果不同，先确认二进制确实重新构建，再排除 CPU 降频、后台进程、输入顺序和容器限额变化。Go 1.26 发布说明提到 Green Tea GC 主要改善小对象标记和扫描的局部性，实际收益会随程序分配形态变化；内存占用不变并不表示功能没有生效。

常见问题：观察 Green Tea GC 时容易误判什么

只看 RSS 下降就能证明 GC 更好吗？

不能。RSS 受分配器保留页、栈、映射和系统回收策略影响，至少要和堆指标、GC 周期及业务延迟一起看。

可以在线上直接设置 GOEXPERIMENT 吗？

不行。它作用于构建过程；要做对照，应使用相同源码重新构建二进制，再在相同负载下比较。

为什么同一程序多次结果不一样？

调度、CPU 频率、后台负载、输入顺序和容器限制都会影响结果。固定实验环境并用多次运行的中位数，通常比单次峰值更可靠。

Go 1.26 的这次变化值得纳入升级检查，但不适合用一句“内存更省”概括。先把实验数据采齐，再决定是否灰度、保留多久的回滚构建，以及哪些业务指标作为上线门槛。