go gc触发有三条件：内存增长达上次存活堆×(1+gogc/100)、超2分钟未gc则定时兜底、runtime.gc()手动强制；gogc是百分比阈值，非绝对内存值，且gc完成不等于内存归还os，后者由scavenger在空闲5分钟或gomemlimit压力下触发。
Go 的 GC 不是“堆一满就收”，而是按比例、看时间、可手动干预——理解这三点，才能准确回答面试题，也才能在生产中真正调优。
GC 触发的三个真实条件：heap 增长、定时兜底、手动强制
Go 运行时源码里明确定义了三种触发方式，对应 gcTriggerKind 枚举：gcTriggerHeap、gcTriggerTime、gcTriggerCycle。面试说“堆满了才 GC”是错的；实际最常用的是第一种，但它的阈值不是绝对值，而是相对值：
-
gcTriggerHeap：当当前堆内存（HeapAlloc） ≥ 上次 GC 后存活堆（HeapLive） × (1 +GOGC/100) 时触发，默认GOGC=100→ 翻倍就触发 -
gcTriggerTime：距离上次 GC 超过forcegcperiod（默认 2 分钟），强制兜底一次，防止长时间无分配导致 GC 彻底不跑 -
gcTriggerCycle：仅用于runtime.GC()手动调用，它不检查条件，直接推进 GC 循环号并启动
注意：runtime.GC() 是同步阻塞的，会等整轮 GC 完成才返回，别在热路径里滥用。
GOGC=100 到底意味着什么？不是“100MB 就触发”
GOGC 是百分比控制参数，和内存绝对值无关。设 GOGC=50，代表“堆增长到上次 GC 后存活堆的 1.5 倍时触发”，不是“用了 50MB 就 GC”。这个设计让 GC 频率随业务负载自然伸缩——流量低时 GC 少，流量高时 GC 密集，但每次回收的“有效垃圾量”更稳定。
- 设
GOGC=-1会禁用自动 GC（仅保留手动runtime.GC()），极少用，调试或嵌入式极端场景才考虑 -
GOGC调低（如 30）会让 GC 更频繁，降低峰值 RSS，但增加 CPU 开销和 STW 次数；调高（如 200）则反向权衡 - 它完全不影响内存归还 OS 的时机——哪怕
GOGC=1，HeapReleased仍要等 scavenger 超时（默认 5 分钟）或GOMEMLIMIT压迫才动作
为什么 pprof 看不到 RSS 涨？因为 GC 和 OS 内存是两层事
面试常被追问：“我 pprof heap 显示 inuse_space 只有 100MB，但 ps aux 看 RSS 有 1.2GB，是不是内存泄漏？”——大概率不是泄漏，而是 Go 运行时没把空闲 span 还给操作系统。
-
pprof::heap只统计 Go 堆中被标记为 inuse 的对象，不包含已清扫但未 scavenged 的 span、mmap分配的大 buffer、cgo 中 C malloc 的内存 - RSS 高于
HeapSys20% 以上，基本可判定存在“非活跃但未归还”的 OS 内存 - 查证手段：
go tool trace看Scavengergoroutine 是否活跃；runtime.ReadMemStats检查HeapReleased是否长期不涨
生产环境最容易踩的坑：混淆 GC 触发与内存归还
开发者最常误以为“GC 跑完 = 内存还给系统了”。实际上，GC 只负责标记清除、复用 span；归还 OS 是 scavenger 的独立逻辑，受两个条件驱动：空闲超时（默认 5 分钟）或内存压力（GOMEMLIMIT 设置后主动施压）。这意味着：
- 别用
GOGC=10试图“让内存快点下去”——它只让 GC 更勤，不加速归还 - 若服务 RSS 持续偏高且
HeapInuse很低，临时加GOMEMLIMIT=80% of RSS可逼 scavenger 提前干活 -
mmap和 cgo 分配的内存完全逃逸出 Go GC 视野，pprof 查不到，得用perf record -e syscalls:sys_enter_mmap或valgrind --tool=memcheck（cgo 场景）定位
真正关键的监控指标不是 GC 次数，而是 HeapReleased 的增长节奏、scavenger 的执行频率，以及 RSS 与 HeapSys 的差值走势。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
