GOGC按存活对象增长量触发GC，不控总堆大小；GOMEMLIMIT才限制总堆上限，二者优先级不同，需协同配置。
Go程序内存不降、GC不触发、OOM频发，通常不是代码写错了，而是参数没对上运行时的真实行为逻辑。GOGC和GOMEMLIMIT不是“调高调低就行”的开关，它们各自控制不同层级的回收条件，且存在优先级关系。
为什么设置了GOGC=50，内存还是涨到2GB才GC？
因为GOGC只管“堆中存活对象大小 × (1 + GOGC/100)”这个增量阈值，不管总内存。比如上一轮GC后存活对象是800MB，设GOGC=50，那要等新分配满400MB才触发——但若这400MB里大部分是短生命周期对象，实际堆占用可能早已突破1.5GB，而GC仍未启动。
-
GOGC不是按总堆比例算的，是按“上次GC后仍存活对象”的增长量算的 - 如果程序有大量临时分配（如高频
make([]byte, 1），这些对象很快变白，但不会拉高“存活对象”基数，导致GC延迟 -
GOGC在低负载时会被forcegcperiod兜底：即使没达阈值，每2分钟也会强制GC一次（Go 1.0.3+默认值）
GOMEMLIMIT比GOGC更早介入内存控制
从Go 1.19起，GOMEMLIMIT是硬性上限，单位支持MB、GB（不区分大小写），一旦进程虚拟内存接近该值，GC会立即被强制触发，甚至跳过常规标记阶段直接回收。
- 设
GOMEMLIMIT=1GB，而实测常驻内存800MB，这是合理余量；设成512MB会导致GC频繁、CPU飙升 -
GOMEMLIMIT包含堆、栈、代码段、mmap映射等所有虚拟内存，不只是runtime.MemStats.HeapSys - 在Kubernetes中必须配
GOMEMLIMIT，否则cgroup memory limit触发OOMKilled时，Go runtime来不及自救
手动调用runtime.GC()几乎总是错的
它会阻塞当前goroutine直到GC完成，且不解决根本问题：空闲内存页（span）仍受scavengelimit约束（默认5分钟），不会立刻归还OS。
- 调用
runtime.GC()后runtime.ReadMemStats显示HeapReleased没变，是正常现象 - 频繁调用反而干扰sysmon的节奏，可能引发GC Assist开销激增
- 唯一合理场景：极少数长周期批处理末尾，确认无后续分配，想主动释放压力
真正影响内存是否“看起来回落”的，不是GC触发时机，而是scavengelimit——这个值决定了空闲span在Go runtime里躺多久才还给操作系统。它不可通过环境变量修改，只能编译时打补丁或升级Go版本调整，默认5分钟，这点最容易被忽略。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
