go垃圾回收机制采用并发标记-清除算法，基于三色标记法（白、灰、黑）与混合写屏障实现低延迟回收，仅在标记准备和标记终止阶段短暂stw，全程由runtime自动触发并支持gogc调优、pprof监控及逃逸分析验证。
Go 的垃圾回收不是靠“背概念”理解的，而是靠观察它怎么动、什么时候动、动完留下什么痕迹——关键在于把 runtime.GC()、GOGC、pprof 和实际内存行为串起来看。
怎么看 GC 实际发生了什么？
别只信文档说“并发三色标记”，得亲眼看到标记阶段在干啥：
- 用
go tool pprof -gc抓一次堆快照，对比两次runtime.ReadMemStats()的NextGC和HeapAlloc，能算出当前触发阈值和离下次 GC 还剩多少字节 - 加
-gcflags="-m"编译，看哪些变量逃逸到堆上——逃逸分析结果直接决定 GC 要管谁 -
debug.SetGCPercent(n)动态改触发比例，配合runtime.NumGC()计数，就能验证“堆翻倍就触发”是不是真按你设的n走
为什么改了 GOGC 还没变？
GOGC 不是立即生效的开关，它只影响下一次 GC 的触发条件：
- 启动时设
os.Setenv("GOGC", "50")有效；运行中调debug.SetGCPercent(50)才能实时生效 - 如果当前堆还没涨到新阈值（比如上次 GC 后存活 10MB，
GOGC=50就得涨到 15MB 才触发），那 GC 就不会来——不是没起作用，是还没到点 -
runtime.GC()强制触发后，下一轮才按新GOGC算，不是“这次就按新值收”
三色标记里“灰色对象”到底指什么？
灰色不是内存里真存了个颜色字段，而是调度器维护的一个工作队列状态：
- 根对象（全局变量、goroutine 栈上指针）初始入灰色队列
- GC worker goroutine 从队列取一个灰色对象，把它所有字段扫一遍：字段指向的白色对象入队变灰，自己变黑
- 所以“灰色”本质是“待扫描但未完成扫描”的对象集合，队列空了，标记阶段就结束
- 混合写屏障会在
*slot = ptr时，把ptr和原*slot都标灰——不是标对象本身，是标它可能漏掉的引用路径
GC 日志里 “mark assist” 是啥？
这是 Go 1.12+ 引入的用户代码协助标记机制，不是错误：
- 当 GC 标记速度跟不上分配速度时，分配内存的 goroutine 会被拉去帮着标几轮——这就是
mark assist - 频繁出现说明堆增长太快，或 GC 被拖慢（比如 CPU 被占满、大量阻塞系统调用）
- 它会增加单次分配延迟，但避免了 STW 时间暴涨；不关它，也别硬压它为零——那是拿吞吐换延迟
真正卡住人的从来不是三色怎么分，而是某次线上接口毛刺查到最后发现是某个 map 值没清空导致对象长期存活，或者 goroutine 泄漏让栈不断膨胀——GC 机制只是舞台，对象生命周期才是剧本。盯着 pprof heap 里 topN 的 alloc_space，比背算法步骤有用得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
