Go语言不实现分代垃圾回收，其runtime中无年轻代/老年代划分，不依赖分代假设，而是采用统一堆结构下的三色并发标记与混合写屏障机制，GC触发仅由GOGC比例和定时器驱动。
Go 语言并不真正实现分代垃圾回收（Generational GC），所谓“分代假设”在 Go 的 runtime 中未被采纳为设计基础。
Go 官方明确不支持分代 GC
从 Go 1.0 到当前最新稳定版（2026 年的 go1.26），runtime 源码中不存在按年龄划分的年轻代/老年代内存区域，也没有基于“大多数对象短命”这一分代假说（Generational Hypothesis）构建的回收策略。Go 团队在多次官方文档与提案（如 proposal: remove generational GC from roadmap）中确认：分代 GC 带来的写屏障开销、跨代引用追踪复杂度，以及对 Go 简单堆结构的破坏，远超其在典型 Go 应用中可能带来的收益。
-
runtime/mgc.go和runtime/mgcsweep.go中无 age 字段、无 generation tag、无晋升逻辑 -
GOGC参数调控的是堆增长比例，而非某一代的回收阈值 - pprof 堆采样（
go tool pprof -heap）输出的对象分布不按年龄分组，只按类型和大小
为什么你常看到“Go 有分代 GC”的误解
这种说法多源于对其他语言（如 Java、V8）机制的类比迁移，或对早期非权威教程的误读。部分混淆点包括：
- “新分配对象在 span 中物理相邻”被误认为是“年轻代”——实际只是分配器局部性优化，与 GC 策略无关
-
runtime.GC()调用后观察到小对象回收快，误以为是“年轻代快速回收”——实则是三色标记对小对象图遍历更快，且其内存块（span）更易被整体归还 - 某些第三方分析工具（如某些 heap visualizer）自行按分配时间着色，但该时间戳并非 runtime 维护的 GC 元数据
Go 真正依赖的替代机制：三色并发标记 + 混合写屏障
Go 用更轻量、更确定性的机制规避了分代 GC 的工程代价：
立即学习“go语言免费学习笔记（深入）”；
- 所有堆对象统一视作同质节点，标记阶段通过
write barrier捕获并发修改，保证正确性 - 清除阶段复用空闲 span，不移动对象，避免了分代所需的“晋升复制”开销
- STW 仅发生在初始标记（
markstart）和标记终止（marktermination）两个微秒级阶段，与对象年龄完全无关 - GC 触发条件纯基于堆增长比例（
GOGC）和后台强制周期（约 2 分钟一次），无代际阈值判断逻辑
真正需要关注的不是“哪一代”，而是对象是否逃逸到堆、是否被长期持有、是否产生循环引用——这些直接影响三色标记的可达性判定，也才是 Go 内存调优的实际入口。
