GC：程序里的自动内存清洁工，看懂垃圾回收底层逻辑

步步糕升

导语

很多开发者初次接触 GC，会误以为它是某个开发框架、性能检测工具。GC（Garbage Collection）即垃圾回收，是编程语言的自动内存管理机制。
程序运行会源源不断创建字符串、对象、查询结果等数据，用完之后如果内存得不到释放，就会出现内存持续上涨、服务卡顿、OOM 内存溢出崩溃。C/C++ 需要开发者手动申请、释放内存；而 GC 机制让运行时自动识别废弃对象、回收内存，把开发者从繁琐易错的内存手工管理中解放出来。
但 GC 不是万能魔法：它只会回收不可达对象；只要对象仍然存在有效引用，哪怕业务逻辑已经不再使用，GC 也不会回收它，这也是托管语言内存泄漏的根本来源。本文结合各主流语言实现，讲解 GC 判定原理、经典算法、Stop‑The‑World 停顿、不同语言内存管理差异，梳理开发中高频误区，适合后端、全栈开发者阅读。

一、GC 如何判定哪些内存可以回收

1. 可达性分析（主流追踪式 GC）

以GC Roots（根对象）作为起点，包括线程栈局部变量、静态全局变量、CPU 寄存器等。从根对象出发顺着引用链遍历，凡是能够直接或间接访问到的对象判定为存活；完全访问不到的对象就是垃圾，可以回收。

举例：局部变量指向一个用户对象，该对象存活；函数执行完毕，变量出栈，没有任何引用指向该对象，就成为待回收垃圾。

2. 引用计数

每个对象维护引用计数器，被引用计数 + 1，引用断开计数‑1；计数归零立刻释放内存。优点是回收及时；致命短板是无法自动处理循环引用：A 引用 B、B 引用 A，外部已经没有访问入口，但互相引用让计数不为零，对象无法被释放，需要额外循环回收辅助处理。

CPython 的 Python 虚拟机就是引用计数为主，配套循环垃圾回收解决循环引用问题。

二、四大经典 GC 基础算法

• 标记‑清除 Mark‑Sweep先标记全部存活对象，再清除未标记垃圾。优点：不需要移动对象；缺点：回收完成后会产生大量内存碎片，大对象分配容易失败。
• 复制算法 Copying将存活对象复制到一块全新内存区域，直接清空旧空间。优点：不会产生内存碎片，新生代大量短命对象场景效率极高；缺点需要预留双倍内存空间，内存开销大。
• 标记‑整理 Mark‑Compact标记存活对象之后，把存活对象向内存一端整体压缩整理，再清理尾部垃圾。优点：无内存碎片；缺点需要移动对象，开销更大，STW 停顿时间更长，多用于老年代回收。
• 分代回收 Generational GC基于行业统计经验：绝大多数对象生命周期很短，创建后很快就失效；只有少数对象长期存活。把堆内存划分为新生代、老年代：新对象分配在新生代，高频快速回收；熬过多次回收的对象晋升到老年代，老年代回收频率更低。兼顾回收效率与停顿开销，Java、C#、V8 JavaScript 广泛采用该策略。
  

三、GC 必须面对的代价：Stop‑The‑World（STW）

GC 工作时，部分阶段需要暂停用户业务线程，也就是 STW（世界暂停）。暂停期间业务代码全部停止执行，会带来接口延迟毛刺。

• 普通业务系统，短暂停顿影响有限；
• 交易系统、实时音视频、游戏、广告竞价这类低延迟场景，STW 停顿会直接影响业务质量。
  

现代 GC 的演进目标，就是尽可能缩短甚至消除 STW 停顿，在吞吐量、停顿时间、内存占用、实现复杂度之间做权衡取舍，不存在绝对完美的 GC 算法。
四、主流编程语言内存管理实现对比

不同语言对 GC / 内存管理选择差异巨大，各有取舍：

• Java（JVM）：可达性分析 + 分代回收，提供 Serial、Parallel、G1、ZGC、Shenandoah 多款收集器。G1 面向通用业务；ZGC 追求亚毫秒级停顿，适合超大堆低延迟服务，调优参数丰富，学习成本较高。
• Go：并发三色标记清扫 GC，尽量让 GC 标记阶段和业务代码并行运行，追求低停顿。开发者不用复杂调参，但频繁创建大量临时对象依然会抬升 GC 压力。
• Python(CPython)：引用计数为主，辅以分代循环 GC 解决循环引用，对象引用归零通常立刻释放内存。
• JavaScript (V8 引擎)：分代回收、增量标记、并发标记；前端、Node 常见内存泄漏来源：未销毁定时器、DOM 引用、全局缓存、闭包长期持有大对象。
• C#/.NET：分代 GC，区分新生代、老年代与大对象堆，支持多种回收模式。
• Swift / Objective‑C：ARC 自动引用计数，编译阶段插入计数管理代码，不属于运行时扫描式 GC；循环引用需要手动使用 weak 弱引用规避。
• Rust：没有传统 GC，依靠编译期所有权、借用检查规则，对象离开作用域自动释放内存，兼顾性能与内存安全，但学习门槛高。
• C / C++：手动申请释放内存，或者依靠智能指针；完全没有自动 GC，性能上限高，但极易出现内存泄漏、野指针、重复释放 bug。
  

核心总结：Java/C# 成熟分代 GC；Go 主打并发低停顿；Python 引用计数 + 循环 GC；JS 引擎内置 GC；Swift 是 ARC；Rust 编译期内存管理；C/C++ 手动管理内存。

五、重点误区：有 GC ≠ 开发者不用关心内存

GC 只会回收不可达对象。即便业务逻辑已经不再使用对象，只要全局 Map、缓存、事件监听器、协程 / 闭包、静态集合仍然持有强引用，GC 就判定对象依旧存活，不会回收，这就是托管语言内存泄漏的根源。
典型泄漏场景：

• 全局容器不断 add 数据，没有过期、清理逻辑；
• 注册事件监听，但程序退出时忘记移除；
• 协程、闭包长期持有大对象；
• 缓存没有设置淘汰过期策略。
  

GC 帮我们省去手动 free，但不代表开发者可以完全无视内存逻辑。
六、开发者高频认知误区澄清

误区 1：GC 是工具，可以手动调用立刻清理内存

纠正：System.gc ()、runtime.GC () 这类调用大多只是给运行时一个建议，不保证立刻执行回收，实际回收时机由运行时策略决定。
误区 2：GC 会回收 “业务上没用的对象”

纠正：GC 只看引用可达性，不理解业务逻辑。只要还有强引用链，业务再无用也不会回收。内存泄漏大多源于此。
误区 3：引用计数可以完美处理全部内存回收，没有短板

纠正：原生引用计数无法处理循环引用，必须额外配套循环检测 GC。
误区 4：有 GC 就不会发生 OOM 内存溢出

纠正：不断新增对象，引用持续不释放，堆内存耗尽，GC 无力回天，依然会出现 OOM 崩溃。
误区 5：STW 停顿可以被完全彻底消除

纠正：现代 GC 极大缩短 STW 时间，但几乎很难做到零停顿；只能做到把停顿压缩到业务可接受范围。
误区 6：Rust 没有 GC 就不会出现内存问题

纠正：Rust 编译期规避传统 GC 泄漏，但依然会出现逻辑层面内存泄漏（例如Box::leak）。
全文总结

GC 垃圾回收，是程序的自动内存清洁工。通过可达性分析或者引用计数识别垃圾对象，借助标记‑清除、复制、标记‑整理、分代四大算法完成内存回收，帮开发者免去手动释放内存的繁琐工作。
GC 运行会带来 CPU 开销与 STW 线程暂停；不同编程语言做出完全不同取舍：Java 多收集器可调优，Go 主打并发低停顿，Python 引用计数，Rust 选择编译期所有权机制，C/C++ 完全手动管理内存。
最重要的一条原则：GC 只会清理已经没有任何引用的对象。如果你代码还握着对象的引用，GC 再强大也无法帮你释放内存。自动内存管理不等于开发者可以放任不管，缓存、全局集合、事件监听、协程闭包，都是内存泄漏高发点。理解 GC 原理，才能排查内存上涨、接口毛刺、OOM 崩溃这类线上问题。