runtime.gc()会强制触发stw式全量gc，阻塞程序且不可控，压测中滥用会导致响应时间失真和gc行为异常；唯一合理场景是专门测量gc对p99延迟的毛刺影响，且需满足流量稳定、单次调用等前提。
runtime.GC() 会阻塞整个程序，且无法控制回收强度
在压测中调用 runtime.GC()，最直接的后果是 STW（Stop-The-World）——所有 Goroutine 暂停执行，直到 GC 完成。这不是“建议回收”，而是强制发起一次完整的、标记-清除式 GC 周期。它不接受参数，无法指定只清理老年代或跳过清扫阶段；Go 运行时会按当前堆状态决定是否启动辅助 GC、是否需要栈重扫等，但这些细节对调用方完全不可控。
常见误判是认为“压测前清一下堆就能让结果更干净”，但实际可能引入两类干扰：
- GC 本身耗时被计入压测响应时间（尤其堆大时，
runtime.GC()可能卡住几十毫秒） - GC 后立即分配新对象，触发新的后台 GC 循环，反而让后续压测阶段的 GC 行为更难预测
压测中手动触发 GC 的唯一合理场景：验证 GC 对延迟毛刺的影响
如果你明确想测量“一次完整 GC 周期对 P99 延迟的冲击”，那 runtime.GC() 是必要手段。但必须满足两个前提：
- 压测流量已稳定（例如已运行 30 秒以上），避免 GC 和冷启动行为耦合
- 仅在单次请求/批次中调用一次，并记录从
runtime.GC()返回到下个请求处理开始的时间差
示例做法（非埋点，仅调试）：
// 在 HTTP handler 或压测 loop 中插入
start := time.Now()
runtime.GC()
fmt.Printf("forced GC took %v\n", time.Since(start))
注意：不要在循环里每轮都调用——这会让 GC 频率远超生产环境，失去参考价值。
替代方案比 runtime.GC() 更可控：GOGC + debug.SetGCPercent
若目标是“让压测过程 GC 行为更稳定”，应避免手动触发，转而调控 GC 触发阈值。Go 默认 GOGC=100，即堆增长 100% 时触发 GC。压测中常因瞬时分配暴涨导致 GC 频繁，此时可临时提高该值：
- 启动前设环境变量：
GOGC=200（延后 GC，减少次数，但单次可能更重） - 运行时动态调整：
debug.SetGCPercent(200)，需 importruntime/debug - 搭配
debug.FreeOSMemory()（慎用）：仅在 GC 后释放内存页给 OS，不影响 GC 触发逻辑
关键区别：debug.SetGCPercent() 不触发 GC，只改阈值；而 runtime.GC() 是立即执行且强阻塞的。
容易被忽略的副作用：PProf 数据失真与调度器扰动
调用 runtime.GC() 后，pprof heap profile 显示的“inuse_space”会骤降，但这不代表应用真实内存压力下降——只是把待回收对象提前清理了。更隐蔽的问题是调度器状态扰动：STW 期间所有 P（processor）被抢占，M（OS 线程）可能被休眠或重建，导致后续几毫秒内 goroutine 调度延迟升高，表现为 pprof trace 中出现异常的“SCHED”事件块。
真正需要关注的不是“能不能手动 GC”，而是压测时是否混淆了 GC 开销和业务瓶颈。比如 P99 突增，优先查 go tool trace 中 GC 标记阶段耗时、辅助 GC 占用 CPU 比例，而不是加一行 runtime.GC() 就以为解决了问题。
