Go GC 变频繁但堆没有明显增长是什么原因

我排查 Go 服务内存时遇到过一个很容易误判的现象：监控里的堆曲线没有明显上扬，GC 次数却越来越密。直觉会把它归结为“内存泄漏”，但这两个信号并不等价。存活堆可以保持稳定，同时程序持续制造大量短命对象；只要分配速度变快，GC 就可能更频繁地工作。

官方资料：https://go.dev/doc/gc-guide

先把“当前还活着多少对象”和“单位时间分配了多少对象”分开看，再对照 GC 周期、堆目标和内存上限。只有确认分配热点后，才适合决定是改代码、调 GOGC，还是设置 GOMEMLIMIT。

稳定堆为什么仍然会频繁 GC

Go 的 GC 触发判断主要围绕上一轮留下的存活堆、GC roots、GOGC 以及本轮新增堆展开。一个请求处理完以后，临时切片、编码缓冲区或中间对象可能很快变成垃圾，所以“回收后还有多少对象”变化不大；但是这些对象在回收前已经产生过分配成本。

可以把现象拆成三种状态：

先用 runtime/metrics 把现象量化

不要只看 RSS 或某一条堆曲线。runtime/metrics 可以同时读取 GC 总周期、存活堆、堆目标和累计分配字节。下面的采样器每隔一段时间打印一次关键值，重点是比较两个采样点之间的增量，而不是迷信某个绝对值。

package main

import (
	"fmt"
	"runtime/metrics"
	"time"
)

func sampleGC() {
	// 读取累计分配、GC 周期和当前存活堆，便于比较时间窗口内的变化。
	samples := []metrics.Sample{
		{Name: "/gc/cycles/total:gc-cycles"},
		{Name: "/gc/heap/live:bytes"},
		{Name: "/gc/heap/goal:bytes"},
		{Name: "/gc/heap/allocs:bytes"},
	}
	metrics.Read(samples)

	// 这些指标不是同一种单位，输出时保留名称，避免把字节误读成次数。
	for _, sample := range samples {
		fmt.Printf("%s = %v\\n", sample.Name, sample.Value)
	}
}

func main() {
	// 采样间隔只用于观察趋势，不改变 GC 的触发策略。
	ticker := time.NewTicker(10 * time.Second)
	defer ticker.Stop()
	for range ticker.C {
		sampleGC()
	}
}

如果两次采样之间 /gc/cycles/total 增长很快，而 /gc/heap/live 基本稳定，再看 /gc/heap/allocs:bytes 是否快速增加。这个组合通常比“堆没有涨，所以没有内存问题”更有解释力。

别把 GOGC 当成泄漏开关

GOGC 决定的是 GC CPU 与内存之间的取舍，不是“允许堆增长多少”的简单开关。按照官方 GC 指南，目标堆大致由存活堆、GC roots 和 GOGC 共同决定。GOGC 越小，目标越近，GC 可能更早开始；GOGC 越大，通常能减少周期频率，但会用更多堆空间。

运行时还支持通过 runtime/debug.SetGCPercent 修改目标百分比。这个 API 适合做有明确边界的实验，不适合在请求路径上反复切换。先记录调整前后的 GC 周期、分配速率和延迟，再决定是否保留。

package main

import (
	"fmt"
	"runtime/debug"
)

func main() {
	// 保存旧值，方便实验结束后恢复调用方原来的 GC 目标。
	old := debug.SetGCPercent(150)
	defer debug.SetGCPercent(old)

	// 这里放一段固定负载，用于对比调整前后的周期和延迟。
	fmt.Printf("旧 GOGC = %d，新 GOGC = %d\\n", old, 150)
}

如果调大 GOGC 后 GC 变少但尾延迟变差，说明你只是把 CPU 压力换成了更大的堆占用或更长的回收工作窗口；如果调小后 CPU 明显上升，也不代表修复了根因。真正应该先处理的是无效分配。

用 alloc_space 找到“谁在持续分配”

当存活堆稳定而 GC 变密时，优先关注累计分配空间，而不是只看当前 in-use。可以打开 pprof 的内存分析接口，然后用 alloc_space 按累计分配量排序。这个视角能把已经被回收的短命对象也纳入判断。

package main

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

func main() {
	// pprof 只绑定本机地址，避免把诊断入口直接暴露到公网。
	server := &http.Server{Addr: "127.0.0.1:6060"}
	log.Fatal(server.ListenAndServe())
}

# 用累计分配空间定位制造短命对象的调用路径。
go tool pprof -sample_index=alloc_space http://127.0.0.1:6060/debug/pprof/heap

常见热点包括每次请求都创建临时格式化缓冲区、重复转换 []byte 与 string、把大对象放进短生命周期容器，以及接口装箱导致的逃逸。修正时要结合业务边界：复用缓冲区、减少中间层复制、缩小对象生命周期，通常比全局调大 GOGC 更稳。

什么时候需要看 GOMEMLIMIT

如果服务运行在容器或有明确内存预算的环境，除了 GOGC，还要考虑 GOMEMLIMIT 或 runtime/debug.SetMemoryLimit。内存上限会让运行时在预算较紧时更积极地安排 GC，但它是软限制，不是对所有外部内存和极端负载的绝对保证。

因此不要用过低的 GOMEMLIMIT 试图“强行压住”所有波动：GC 可能为了守住限制而占用更多 CPU，结果表现为回收更频繁、吞吐下降。先确认服务的 RSS、非 Go 内存、并发峰值和分配热点，再给上限留出合理余量。

我会按这个顺序修正

1. 先确认监控采集的是存活堆、堆目标还是进程 RSS，避免把不同口径放在一条曲线上解释。
2. 记录一段时间的 /gc/cycles/total、/gc/heap/live、/gc/heap/goal 和累计分配量，确认是分配速率变化还是目标变小。
3. 用 alloc_space 找到分配热点，优先减少复制、临时对象和不必要的字符串转换。
4. 在固定负载下小范围实验 GOGC；有容器内存预算时，再评估 GOMEMLIMIT 对 CPU 和延迟的影响。
5. 保留调整前后的指标窗口，防止“GC 少了”却漏掉尾延迟和 RSS 上涨。

相关问题

堆没有增长是不是就没有内存泄漏？

不能这样判断。堆曲线稳定只能说明当前存活对象没有明显增加，仍可能存在分配过多、缓存抖动、外部内存增长或采集口径不完整的问题。

直接把 GOGC 调大可以吗？

可以作为受控实验，但它是在 CPU 和内存之间换空间。若分配热点没有变化，调大 GOGC 只能让垃圾晚一点被处理，并不会让这些对象消失。