runtime.GC() 是手动触发 GC，但几乎不该在生产代码里调用
它强制运行一次垃圾回收，看起来能“立刻释放内存”，实际却容易打乱 Go 运行时的 GC 节奏，导致 STW 时间不可控、CPU 突增、甚至引发更多分配压力。Go 的 GC 是并发、自适应的，runtime.GC() 会打断它的节奏，尤其在高负载服务中可能让延迟毛刺变多。
常见错误现象：runtime.GC() 被写在 HTTP handler 末尾、“清理内存”逻辑里，或配合 runtime.ReadMemStats() 做“内存监控闭环”。结果是压测时 P99 延迟跳升，GC 频次反而上升。
- 只在极少数调试场景用：比如跑完一段大量临时对象生成的离线计算后，想立刻观察堆大小变化
- 调用前确保当前 goroutine 不在关键路径上（例如不在 HTTP 处理、数据库事务中）
- 永远不要加循环或定时器自动调用——Go 不需要你“帮它打扫”
如何安全获取协程数量：别信 goroutines()，用 runtime.NumGoroutine()
runtime.NumGoroutine() 返回当前存活的 goroutine 总数，是唯一稳定可用的统计入口。网上有些代码用 debug.ReadGCStats() 或遍历 /debug/pprof/goroutine?debug=1 解析文本，既慢又易错，还依赖 pprof 启用状态。
使用场景：告警阈值监控（如 >5000 协程持续 30 秒）、压测中判断协程泄漏、HTTP 中间件记录并发量快照。
立即学习“go语言免费学习笔记（深入）”；
- 该函数开销极低，可高频调用（每秒几十次没问题）
- 返回值包含所有状态的 goroutine：running、runnable、waiting（含 channel wait、syscall、timer 等），不只是“正在跑”的
- 注意它不区分用户 goroutine 和 runtime 自身创建的（比如 netpoll、timerproc），所以突增未必代表业务泄漏
控制 GC 频率：GOGC 环境变量比代码里调用更可靠
想降低 GC 频率？改 GOGC 环境变量就行，比如启动前 GOGC=200 表示当堆增长到上次 GC 后两倍时才触发下一次。这是 Go 运行时最直接、最稳定的 GC 控制开关。
为什么不用 debug.SetGCPercent()？它虽能 runtime 修改，但副作用明显：修改后下一次 GC 才生效，且无法回滚到默认值（-1 表示恢复默认，但某些旧版本有 bug）；更重要的是，它只影响当前进程，无法被容器编排系统感知和配置。
- 设太低（如
GOGC=10）会导致 GC 过于频繁，CPU 白白消耗在扫描上 - 设太高（如
GOGC=800）会让堆长时间不回收，RSS 持续上涨，可能被 OOM killer 干掉 - 云环境建议从
GOGC=100（默认）起步，根据 RSS 和 GC CPU 占比微调；内存敏感型服务可试150，延迟敏感型可试75
runtime.MemStats 里的 Alloc 和 Sys 容易看反，它们根本不是“已用/总内存”
Alloc 是当前堆上还活着的对象占用的字节数（即“活跃堆大小”），Sys 是 Go 向操作系统申请的总虚拟内存（含未映射页、栈、runtime 元数据等）。两者差值远不止“空闲内存”，也完全不能用来算“还能分配多少”。
典型误用：把 MemStats.Sys - MemStats.Alloc 当作“可用内存”，然后做限流或拒绝请求——这会导致过早拒绝，因为大部分 Sys 空间根本不能用于新对象分配（比如栈空间、保留但未提交的 heap 区域）。
- 真正反映压力的是
HeapInuse（已提交并正在用的堆页）和NextGC（下次 GC 触发点） - 监控推荐组合：
HeapInuse / HeapSys看堆利用率，NumGC+PauseNs看 GC 频次与停顿分布 - 每次读
runtime.ReadMemStats()前记得先声明var m runtime.MemStats，否则局部变量逃逸可能导致额外分配
事情说清了就结束。GC 行为和协程统计看似简单，但 runtime 包里每个字段和函数背后都有调度器、内存分配器、标记清除流程的耦合，动一个参数常牵出三个隐性代价。
