Go GC 占 CPU 5%，到底要不要调 GOGC？

Thu, 21 May 2026 23:30:00 +0800

服务 p99 每隔几十秒抖一下。

监控里 GC CPU 大概 5%，不算夸张，但曲线很准：GC 一来，延迟就往上冒。群里很快有人提议：把 GOGC 从 100 调到 200，先让 GC 少跑几次。

这个动作看起来很合理。

CPU 下来了，GC 日志没那么密了，p99 也安静了几天。然后另一个问题来了：容器内存开始逼近 limit，某个高峰期被 OOMKilled。大家又把 GOGC 调回去，延迟抖动也跟着回来。

这就是很多 Go GC 调优的真实状态：不是不会调参数，而是没想清楚自己到底在买什么。

GOGC 调的是账期，不是魔法。

调高它，相当于允许堆多长一段时间，用内存换 CPU；调低它，相当于让 GC 更勤快，用 CPU 换内存。至于 GOMEMLIMIT，它不是另一个版本的 GOGC，而是在告诉 runtime：这个进程由 Go 管的内存，最好别越过这条线。

所以这篇不打算把 GC 参数逐个解释一遍。线上真正需要的是一条决策路径：要不要调，调什么，调多少，什么时候停手。

先别问 GOGC 设多少，先问谁在付账

Go 官方 GC Guide 给过一个很关键的公式：

1

Target heap memory = Live heap + (Live heap + GC roots) × GOGC / 100

这句话不用背，抓住意思就行。

Thu, 23 Apr 2026 20:00:00 +0800

凌晨三点，线上容器启动要三分钟。

你登上服务器，docker images 一看：2.1GB。PM 问为什么这么慢，你说"容器已经很快了"。

但容器不是虚拟机。你把 Docker 当 VM 用，它当然慢。

问题不在 Docker，在你没理解它到底是什么。

很多人以为 Docker 只是把代码和依赖打包进一个盒子，但依然不知道为什么上了生产就崩。你可能正在给一个简单的 Node.js 应用构建 2GB 的镜像，硬编码环境变量，容器启动要三分钟。

容器不是虚拟机。 它不需要 hypervisor，不需要臃肿的 guest OS。它是一个与宿主机内核直接共享的进程。

看完这篇，你能写出高效 Dockerfile，不再把容器当虚拟机用。

虚拟机通过 hypervisor 模拟物理硬件。每个 VM 运行独立的操作系统和应用。

VM 有三大痛点：

Docker 虚拟化的是操作系统，不是硬件。容器共享宿主机内核，只隔离用户空间的进程、库和依赖。

容器优势：