runtime.GC() 是什么，什么时候该调用
runtime.GC() 是 Go 运行时提供的一个同步强制垃圾回收函数。它会阻塞当前 goroutine，直到一轮完整的 GC 周期完成（包括标记、清扫等阶段）。它不是“建议 GC”，而是“立刻执行一次完整 GC”。
真实场景中极少需要手动调用：
- 服务启动后预热阶段，想清掉初始化产生的临时对象？通常没必要，Go 的 GC 已足够智能
- 内存敏感的批处理任务（如图像批量处理）结束后，想立刻释放大块内存？这是较合理的使用场景
- 在 pprof 测试前后强制 GC，排除 GC 干扰？可行，但要注意它本身会拖慢测试节奏
调用 runtime.GC() 的常见错误现象
直接在 HTTP handler 或高频 goroutine 里写 runtime.GC()，常导致以下问题：
- HTTP 响应延迟突增：一次
runtime.GC()可能卡住几十毫秒到几百毫秒（尤其堆大时） - GC 频率反而升高：手动触发后，运行时可能误判为“内存压力大”，提前开启下一轮 GC
- 和后台 GC 冲突：Go 1.22+ 默认启用并行标记，
runtime.GC()会等待所有并发标记 worker 完成，实际耗时比预期长 - 压测时出现
runtime: mark stack overflow：强制 GC 期间若栈上仍有大量活跃指针，可能触发该 panic（少见但存在）
替代方案比 runtime.GC() 更稳妥
多数情况下，与其硬触发，不如调整 GC 行为或释放资源源头：
- 用
debug.FreeOSMemory()归还闲置内存给操作系统（注意：它不触发 GC，只调用madvise(MADV_DONTNEED)；且仅对大块空闲 span 有效） - 设低延迟目标：
debug.SetGCPercent(10)（默认是 100），让 GC 更早介入，避免单次停顿过长 - 及时 nil 掉大对象引用（如切片、map、结构体字段），帮助 GC 准确识别可回收内存
- 用
sync.Pool复用临时对象，从源头减少 GC 压力，比事后清理更高效
如果真要调用，必须加防护和观察
硬性要求：只在明确知道代价、有监控兜底、且有 fallback 的路径下调用。
立即学习“go语言免费学习笔记（深入）”；
- 加超时控制：用
time.AfterFunc或 context 包包裹，防止 GC 卡死整个流程 - 加计数器和日志：记录调用次数、耗时、堆大小变化（
runtime.ReadMemStats），否则无法评估是否起效 - 避开高峰期：不要在请求高峰、定时任务密集期、或 pprof 正在采样时调用
- 确认 Go 版本行为：Go 1.21+ 中
runtime.GC()不再阻塞世界停止（STW）全部 goroutine，但标记阶段仍需暂停，不同版本表现略有差异
GC 本身是运行时自治过程，手动干预就像在自动变速箱车上猛踩离合——偶尔有用，但多数时候只是暴露了对负载或内存模型的理解偏差。
