runtime.SetGCPercent() 不能在 init() 中调用，因为此时 GC 尚未初始化，调用会静默失败（返回 -1），导致内存缓慢增长至 OOM；正确时机是 main() 开头、业务分配前，并应配合 runtime.ReadMemStats() 验证生效。
runtime.SetGCPercent() 为什么不能在 init() 里调用
因为 runtime.SetGCPercent() 必须在 GC 初始化完成后才能生效，而 init() 阶段 runtime 还没完成堆初始化，此时调用会静默失败——返回值是 -1，但很多人没检查。线上曾有服务在 init() 里设 SetGCPercent(50)，结果 GC 一直按默认 100 运行，内存缓慢爬升到 OOM。
正确时机是 main() 开头、任何业务分配前，且建议配合 runtime.ReadMemStats() 验证：
func main() {
old := runtime.SetGCPercent(50)
if old == -1 {
log.Fatal("failed to set GOGC: runtime not ready")
}
var m runtime.MemStats
runtime.ReadMemStats(&m)
log.Printf("GOGC applied, heap alloc: %d MB", m.HeapAlloc/1024/1024)
// 后续启动 HTTP server / goroutines
}
- 不要在包级变量初始化或
init()中调用 - 不要依赖环境变量
GOGC="50"（带引号会被 Go runtime 忽略），必须无引号或用SetGCPercent - 设完后立即读一次
MemStats，确认不是“设了等于没设”
GOMEMLIMIT 比 GOGC 更值得优先设置
GOMEMLIMIT 是 Go 1.19+ 引入的硬性内存闸门，它限制的是整个进程的虚拟内存上限（含堆、栈、代码段、mmap 区），一旦接近该值，GC 会强制触发，哪怕堆才涨了 10%。这在容器环境（如 Kubernetes）中是防 OOMKilled 的关键防线。
典型错误是只调 GOGC 却忽略 GOMEMLIMIT，导致节点内存紧张时被 kernel 直接杀掉，连 GC 的机会都没有。
- 设值建议：压测实测稳定 RSS + 20% 缓冲，例如常驻 800MB →
GOMEMLIMIT=1GB - 单位不区分大小写：
1.2GB、1200MB、1258291200B等价 - 和
GOGC共存时，GOMEMLIMIT优先级更高 —— 它是兜底，不是可选项 - Kubernetes 中应通过
resources.limits.memory和GOMEMLIMIT双重对齐，避免错位
gctrace=1 日志里 “12->12->8 MB” 到底在说什么
这是 GC 跟踪中最容易误读的一行：gc 12 @3.456s 0%: 0.012+0.45+0.008 ms clock, 0.096+0.12/0.28/0.51+0.064 ms cpu, 12->12->8 MB, 13 MB goal。其中 12->12->8 MB 不是“用了 12MB，释放到 8MB”，而是：
- 第一个
12：GC 开始前堆中**存活对象**大小（即标记结束时黑色对象总和） - 第二个
12：GC 开始前堆中**已分配但未回收**的总字节数（含白色垃圾） - 第三个
8：GC 结束后堆中**存活对象**大小（即本轮回收后实际保留的）
所以 12->12->8 表示：本轮 GC 前有 12MB 存活对象，共占 12MB（说明没垃圾），回收后剩 8MB —— 实际是发生了 **对象死亡**，不是内存压缩。如果长期看到 X->X->X（三数相等），说明几乎没有对象被回收，大概率存在内存泄漏或对象复用失效。
pprof heap profile 显示 alloc_objects 高但 inuse_objects 低
这是典型的“高频短命对象”模式：代码每秒分配上万次小对象（如 make([]byte, 128)），但每个只活几毫秒。这类问题不会立刻爆内存，但会显著抬高 GC 频率和 CPU 占用（runtime.gcDrainN 成 top 函数）。
排查路径很直接：
- 用
go tool pprof -alloc_objects http://host:port/debug/pprof/heap找 top 分配点 - 对 top 函数执行
traces，看是否在 hot loop 里反复构造（比如循环中json.Unmarshal同一份数据 6 次） - 优先改代码：提取公共解析结果、用
sync.Pool复用结构体、避免interface{}逃逸 - 参数调优只是缓兵之计：
GOGC=50可能让 GC 更勤快，但治标不治本；GOMEMLIMIT设太低反而会让 GC 更频繁抢 CPU
真正卡点往往藏在看似无害的封装函数里 —— 比如一个 ToString() 方法内部每次 new 一个 bytes.Buffer，被高频调用时就成了 GC 泵。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
