面试答GC要聚焦三点：何时停、为何停、如何减停；三色标记非重点，写屏障实现才是关键；Go 1.8+混合写屏障将STW压缩至两次极短暂停；慎用runtime.GC()，优先调GOGC或debug.SetGCPercent()。
直接说结论：面试时答 GC，别堆术语，重点讲清「什么时候停、为什么停、怎么减少停」——这三点覆盖了 90% 的追问。
三色标记法不是考点，写屏障才是关键分歧点
很多人背“白灰黑”流程，但面试官真正想听的是你是否理解它为什么需要写屏障。三色标记本身只是模型，真正决定 STW 时长和正确性的，是写屏障的实现方式。
- Go 1.5 用插入写屏障（Dijkstra），但栈上不启用 → 必须在标记结束前 STW 重扫栈，否则新分配对象可能漏标
- Go 1.8+ 改用混合写屏障：GC 开始前把所有 goroutine 栈一次性置黑，之后栈上新对象直接标黑，堆上同时启用插入 + 删除写屏障
- 这意味着：STW 只剩两次，且都极短 —— 第一次仅扫描根对象（
runtime.scanstack），第二次仅做终止标记（marktermination）
runtime.GC() 是个危险信号，慎用
调用 runtime.GC() 会强制触发一轮完整 GC，包括两次 STW 和并发标记/清除。它不会帮你“优化内存”，反而可能打乱 runtime 自适应的回收节奏。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 常见误用场景：看到内存上涨就手动调
runtime.GC()，结果导致毛刺上升、延迟抖动 - 真正该调的不是
runtime.GC()，而是观察GOGC环境变量是否合理（默认 100，即堆增长 100% 触发 GC） - 若需干预，优先考虑
debug.SetGCPercent()动态调整，而非硬触发
GC 日志里最该盯住的两个字段：gc %d @%v 和 pause
开 GODEBUG=gctrace=1 后输出的日志里，真正反映 GC 健康度的不是“有没有 GC”，而是每次 GC 的暂停时间和触发时机是否稳定。
立即学习“go语言免费学习笔记（深入）”；
-
gc 1 @0.012s 0%: 0.002+0.024+0.002 ms clock, 0.016+0/0.004/0.016+0.016 ms cpu, 4->4->2 MB, 5 MB goal中的0.002+0.024+0.002 ms clock就是三次 STW 总耗时（单位毫秒） - 如果
pause超过 1ms（尤其在低延迟服务中），要查是否发生了栈重扫、是否GOMAXPROCS过低导致标记 goroutine 不足 -
4->4->2 MB表示标记前堆大小、标记后堆大小、清除后堆大小；若中间值（标记后）远高于首尾，说明标记阶段对象存活率高，可能是内存泄漏征兆
真正容易被忽略的点是：GC 行为高度依赖程序的分配模式。比如高频小对象分配会快速填满 mcache，触发更频繁的清扫；而大对象直接走 mheap 分配，影响的是页级管理。不看分配热点，只调 GC 参数，基本是蒙眼调优。
