go gc是低延迟与高吞吐权衡的并发系统，采用三色标记法与混合写屏障实现微秒级stw，内存分配受逃逸分析影响，触发时机由gogc参数调控。
Go 的垃圾回收（GC）不是“后台静默工作”的黑盒，而是一套在低延迟与高吞吐之间持续权衡的并发系统。它不依赖开发者手动释放内存，但其行为会真实影响程序响应时间、CPU 占用和内存峰值——尤其在高并发服务或短生命周期对象密集的场景中。
三色标记法：如何安全识别“垃圾”
Go 从 1.5 版本起采用并发三色标记（Tri-color Marking），核心是把堆上对象分为三种逻辑状态：
- 白色：初始状态，表示“尚未扫描，可能是垃圾”；
- 灰色：已入队待扫描，但其引用的对象还未检查；
- 黑色：已扫描完成，且它引用的所有对象也都被标记为可达。
标记过程从根对象（如全局变量、栈上指针）出发，逐步将灰色对象转为黑色，并把其引用的白色对象转为灰色。最终所有存活对象都会变成黑色，剩余白色对象即为可回收垃圾。
为保证并发标记时程序（Mutator）修改指针不导致漏标，Go 引入混合写屏障（Hybrid Write Barrier）：当程序向对象字段写入新指针时，运行时会确保被覆盖的旧对象或新指向的对象至少有一个被重新标记为灰色。这避免了 STW（Stop-The-World）延长，也让 GC 能与业务代码真正并行执行。
立即学习“go语言免费学习笔记（深入）”；
STW 时间已大幅压缩，但仍未归零
Go 的 STW 并非只发生在 GC 开始前——它分两个极短阶段：
- 标记开始前：暂停所有 goroutine，扫描栈和全局变量，构建初始灰色集（通常
- 标记结束前：再次暂停，重新扫描可能因写屏障未覆盖而变动的栈（同样微秒级）。
从 Go 1.8 起，这两个阶段已稳定控制在百微秒内；1.12 后进一步优化栈重扫描效率。这意味着对大多数 HTTP 服务，GC 几乎不会造成可观测的请求延迟毛刺。但若应用存在大量 goroutine 或深度嵌套栈帧，仍需关注 STW 尾部延迟。
内存分配与逃逸分析直接影响 GC 压力
GC 只管理堆内存。是否分配到堆，取决于编译器的逃逸分析结果：
- 局部变量若未逃逸（如小结构体、短生命周期切片），直接分配在栈上，函数返回即自动释放，完全不参与 GC；
- 一旦发生逃逸（例如返回局部变量地址、传入接口、存入全局 map），对象就会被分配到堆，进入 GC 生命周期。
可通过 go build -gcflags="-m" 查看变量逃逸情况。减少不必要的逃逸（比如避免频繁构造大结构体后取地址、复用对象池中的 buffer）能显著降低标记工作量和堆内存增长速度。
GC 触发时机与调优关键参数
默认情况下，Go 使用基于堆增长率的触发策略：当新分配的堆内存达到上一次 GC 后存活堆大小的 100%（即 GOGC=100）时，启动下一轮 GC。例如，若上次 GC 后存活 10MB，则新增 10MB 分配就会触发 GC。
- 调高
GOGC（如设为 200）可降低 GC 频率，换得更高吞吐，但会增加内存占用； - 调低
GOGC（如设为 50）则更激进回收，降低内存峰值，但 CPU 开销上升； - 生产环境建议结合监控（如
runtime.ReadMemStats中的NextGC和HeapAlloc）动态观察，而非盲目调参。
不复杂但容易忽略。
