GreenTea垃圾回收器观察堆行为

Go 的 Green Tea 垃圾回收器，真正值得观察的不是“名字换了”，而是标记和扫描工作更倾向于按内存 span 聚合，再批量处理同一片区域里的对象。Go 1.25 先把它作为实验能力提供，Go 1.26 起默认启用；到了现在，排查堆行为时更重要的是知道如何读证据，而不是手动切换回旧实现。

官方资料：https://go.dev/blog/greenteagc

观察 Green Tea 要把三个问题分开：GC 什么时候发生、堆的目标和存活量怎么变化、哪些代码路径真正保留了对象。gctrace 适合看周期，runtime/metrics 适合做连续采集，pprof heap 适合追分配来源；三者拼起来，才接近“堆行为”。

我先确认的不是性能，而是运行时版本

我第一次接触 Green Tea 时，最容易犯的错是看到官方文章里的 10%～40% 就开始期待业务延迟下降。这个数字是官方基准和特定工作负载的观察，不是每个服务的承诺。先把 Go 版本写进排查记录，能避免把 Go 1.25 的实验开关、Go 1.26 的默认行为和更高版本混成同一种状态。

# 先确认编译器版本，避免把实验行为和默认行为混在一起
go version
# 查看当前构建环境中的实验开关，记录它而不是凭印象猜测
go env GOEXPERIMENT

Go 1.25 的实验写法是构建时设置 GOEXPERIMENT=greenteagc。Go 1.26 把 Green Tea 设为默认实现，并提供过 GOEXPERIMENT=nogreenteagc 的回退入口。当前项目如果已经使用 Go 1.26 或更高版本，我会先保持默认配置，只有在做明确的对照实验时才记录构建参数。不要把旧教程里的实验开关直接塞进生产构建脚本。

Green Tea 改变了哪一步

Go 的垃圾回收仍然是并发的标记-清扫路线，Green Tea 不是把整个 GC 换成了完全不同的内存管理模型。变化集中在标记和扫描如何组织工作：传统路径更像沿着对象图不断取出对象并跳转；Green Tea 会在同一个内存 span 中累积待扫描对象，再成批扫描。

这样做的收益来自更连续的内存访问、更少的元数据访问压力，以及给预取或向量化留下空间。官方资料也特别提醒，工作负载仍然重要：如果对象分布很散，单个页面里可一次处理的对象很少，聚合成本可能抵消部分收益。因此“Green Tea 已默认启用”不等于“应该删掉所有堆观测”。

我会把它当作底层执行路径的变化，而不是应用层的调优按钮。应用依旧可能因为缓存、全局切片、长生命周期队列或 goroutine 持有引用而让存活堆持续增长；这些问题不会因为扫描局部性更好就自动消失。

先用 gctrace 看每轮 GC 的形状

想回答“GC 什么时候变频繁、每轮回收了多少”，最短路径是打开 gctrace。它把摘要写到标准错误，适合在一次压测或复现窗口里临时开启，不建议把未经整理的完整日志永久写入高流量业务日志。

# 只在一次可控的压测窗口打开 GC 摘要，并把标准错误单独保存
GODEBUG=gctrace=1 go run . 2>gc.log
# 让日志和本次构建版本、请求负载一起归档，便于做前后对照
go version > go-version.txt

一行 gctrace 通常会同时给出 GC 周期、GC 开始前后的堆规模、存活堆和暂停摘要。这里最有用的不是盯着某一行的毫秒数，而是观察一段时间内的形状：

• 堆目标增长而存活堆也持续增长，优先怀疑对象确实被业务引用着，而不是先怀疑 GC 算法。
• 分配速度相近但 GC 周期明显变密，说明内存预算、对象短命程度或负载阶段发生了变化。
• 暂停摘要稳定但 GC CPU 变高，说明不能只用“暂停很短”判断 GC 成本。

gctrace 是时间线证据，不是保留对象的调用栈。看到异常形状后，我会转到 runtime/metrics 和 pprof，而不是继续扩大日志级别。

用 runtime/metrics 做连续观察

如果要把堆行为放进服务指标，runtime/metrics 比定期打印完整 runtime.MemStats 更适合做窄而稳定的采集。可以先采集存活堆、堆目标、堆对象数和 GC CPU 总量；指标名是字符串，运行时版本升级后应以当前版本的 metrics.All() 为准。

package main

import (
	"fmt"
	"runtime/metrics"
)

func main() {
	// 只采集回答堆行为所需的少量指标，避免把所有运行时指标都打进日志。
	samples := []metrics.Sample{
		{Name: "/gc/heap/live:bytes"},
		{Name: "/gc/heap/goal:bytes"},
		{Name: "/gc/heap/objects:objects"},
		{Name: "/cpu/classes/gc/total:cpu-seconds"},
	}
	metrics.Read(samples)

	for _, sample := range samples {
		// 这些指标都是 uint64；若后续替换指标，先检查 Value.Kind 再取值。
		if sample.Value.Kind() == metrics.KindUint64 {
			fmt.Printf("%s=%d\n", sample.Name, sample.Value.Uint64())
		}
	}
}

其中 /gc/heap/live:bytes 是上一次 GC 标记出的存活堆，/gc/heap/goal:bytes 是运行时当前的堆目标，二者一起看比单独看进程 RSS 更接近 GC 的决策背景。/cpu/classes/gc/total:cpu-seconds 是 GC 任务累计消耗的估算 CPU 时间，适合比较同一负载下的前后趋势，不应直接当成操作系统进程 CPU 百分比。

把 pprof heap 用来追“谁还留着对象”

当存活堆涨了，下一问通常是“哪条调用路径让对象活着”。这时需要 heap profile。它反映最近一次完成 GC 后的存活对象采样，因此它和实时分配日志的口径不同；这也是我不会只看一次 profile 就下结论的原因。

package main

import (
	"log"
	"net/http"
	_ "net/http/pprof"
)

func main() {
	// 诊断端口只绑定本机，避免把 pprof 直接暴露给外部网络。
	go func() {
		if err := http.ListenAndServe("127.0.0.1:6060", nil); err != nil {
			log.Printf("pprof stopped: %v", err)
		}
	}()

	// 这里继续启动业务服务；示例省略业务路由，重点是 pprof 的接入方式。
	select {}
}

# 采集一份堆快照，文件名带上场景和时间，避免覆盖不同负载的数据
curl -o heap.pprof http://127.0.0.1:6060/debug/pprof/heap
# 先看存活对象占用，再回到代码检查是否有长期引用
go tool pprof -top heap.pprof

pprof 的 heap profile 默认偏向显示存活对象占用，并且以最近一次完成 GC 为时间点。若想看“从进程启动到现在累计分配了谁”，可以在 pprof 中选择 alloc_space，但它回答的是累计分配，不是当前仍然存活。两者混用，会把短命对象的分配热度误认为泄漏。

三条观察线如何拼成一个判断

我实际整理记录时，会把同一个负载窗口里的证据按下面的顺序放在一起：

1. 先看 gctrace：确认 GC 周期是否变密，堆开始/结束和暂停摘要是否出现明显转折。
2. 再看 metrics：用 live、goal、objects 和 GC CPU 的时间序列判断，是存活堆变大，还是分配节奏变快。
3. 最后看 pprof：把存活对象的热点栈映射回缓存、队列、请求上下文或全局引用，形成可修改的代码假设。

例如，gctrace 显示周期变密，metrics 显示 live 基本不变而 GC CPU 上升，可能更接近短命对象分配压力；如果 live 和 objects 都持续上行，pprof 中又出现同一缓存构造函数占据主要空间，排查方向就应该落在缓存淘汰或引用生命周期。这里的“可能”很重要：采样、负载和采集时机都会影响结果，不能只拿一张图当最终证据。

哪些做法容易把 Green Tea 看错

• 把官方收益当成单机承诺：官方给出的范围来自基准和真实工作负载观察，业务对象图不同，收益可能不同。
• 只比较一次压测总耗时：至少固定 Go 版本、CPU、GOMAXPROCS、输入数据和请求节奏，再比较 GC CPU、live、goal 与尾延迟。
• 把 RSS 当作存活堆：RSS 还包含运行时保留空间、栈、文件映射和其他内存类别，不能直接替代 heap profile。
• 长期打开 gctrace：它适合短窗口诊断；生产环境长期运行应优先选受控 metrics，并把日志采集成本算进去。
• 用旧实验开关排查新版本：先阅读当前版本 release notes，记录实际构建参数，不要机械复制 Go 1.25 的教程。

我会留下的最小观察清单

Green Tea 的价值在于让运行时更贴近现代 CPU 的局部性和并行能力，但应用工程师仍然要回答“对象为什么活着、分配从哪里来、GC 成本占在哪里”。用三条观察线把答案串起来，比单独讨论“新 GC 快不快”更可靠。

相关问题

Go 1.25 还能手动启用 Green Tea 吗？可以在构建时使用 GOEXPERIMENT=greenteagc，但要结合该版本官方说明记录实验状态。

Go 1.26 以后还要设置 greenteagc 吗？默认已经启用，通常不需要把实验开关写进构建命令；是否存在回退开关要以具体版本 release notes 为准。

heap profile 能直接证明内存泄漏吗？不能。它是采样和 GC 时间点快照，应结合多次采集、对象生命周期和业务引用一起判断。

Green Tea 会改变 Go 代码的 GC 语义吗？它主要改变运行时标记扫描的组织方式，应用仍应按正常 Go 语义处理引用、生命周期和资源释放。