垃圾回收基础：引用计数、标记清除、分代收集
说到内存管理，垃圾回收（GC）是绕不开的话题。很多开发者在实战中遇到内存泄漏，往往是因为对GC的运作机制理解得不够透彻。我个人习惯把GC看作是一种“自动内存管家”，它帮我们回收那些不再使用的对象。但这位管家也有自己的脾气和局限性，搞不懂它的运作逻辑，就很容易出问题。
今天我来系统地梳理一下三种最核心的GC算法。把它们吃透了，很多内存泄漏的根因你一眼就能看穿。
引用计数：最直观但致命的陷阱
引用计数的思想非常简单。每个对象身上都带一个“计数器”，记录着有多少指针指向它。当有新的引用指向它时，计数器加1；当引用被销毁时，计数器减1。如果计数器降为0，对象就被视为“垃圾”，立即回收。
这听起来很完美，对吧？我年轻时也这么认为，直到在一个大型C++项目中遇到了臭名昭著的循环引用问题。
// 这是一个典型的循环引用场景
public class Parent {
Child child;
}
public class Child {
Parent parent;
}
// 外部引用置 null
var p = new Parent();
var c = new Child();
p.child = c;
c.parent = p;
p = null;
c = null;
// 此时 p 和 c 占据的内存无法被回收！
避坑指南：如果你在使用Python、PHP或早期的Objective-C，一定要警惕循环引用的场景。我曾经在一个负责图形渲染的模块里，因为节点树中的父子互相引用，导致大量“活僵尸”对象。
解决方案通常是：用弱引用（Weak Reference）打断引用环，或者依赖更高级的GC算法来做兜底处理。
标记清除：解决问题的关键一步
标记清除算法就是为了解决引用计数的“循环引用”而生的。它的做法是分两步走：
- 标记阶段（Mark）：从被称为“GC Roots”的根集合出发（比如栈里的局部变量、静态变量），遍历所有可达的对象。能访问到的，就打个标记。
- 清除阶段（Sweep）：遍历整个堆，把那些没有标记的对象，直接当作垃圾回收掉。
你看，它不依赖对象的计数，而是看是否可达。所以在标记清除眼中，循环引用的对象只要外部没根了，就会一起被标记为垃圾清理掉。说白了，这才是真正意义上的“垃圾回收”。
但记住，它也有硬伤：
- STW（Stop The World）：标记和清除时，必须暂停所有工作线程。如果堆很大，这个暂停时间会非常可怕。
我记得线上曾经有一个Java应用，每次GC都会导致几秒钟的“卡顿”，用户直接炸了。后来优化了堆大小和GC策略才解决。 - 内存碎片：清除后，空闲内存是不连续的。这会导致分配大对象时，明明总空间够，但就是找不出连续的大块区域，被迫再次触发GC。
分代收集：工程实践的智慧结晶
为了解决标记清除的停顿问题，工程师们发明了分代收集。这个理论基于一个我每天都在观察的事实——“弱分代假说”：绝大多数对象，在创建之后很快就死掉了。
你想想看，一个循环里的临时变量、一个列表里的迭代器，它们通常活不过几毫秒。只有少部分对象会长期存活，比如缓存、单例对象。
基于这个观察，分代收集把堆划分成几个区域：
| 代 | 特点 | GC频率 | 收集算法 |
|---|---|---|---|
| 新生代（Young） | 对象刚创建，死亡率高 | 高，非常频繁 | 标记复制（速度快，无碎片） |
| 老年代（Old） | 经过多次Young GC幸存下来的对象 | 低，相对低频 | 标记清除 或 标记整理 |
| 元空间/永久代（Meta） | 存储类元数据等 | 特殊情况触发 | 特定回收机制 |
实战经验：如果新生代GC（Minor GC）非常频繁，甚至每几秒一次，通常说明你的临时对象创建得太多了，或者新生代空间设置过小。
但如果发生的是老年代GC（Full GC / Major GC），那就得小心了——这往往是内存泄漏或者系统负载过高的信号。我个人习惯在监控上重点关注Full GC的频率和持续时间。
三种算法怎么选？
没有银弹。三种算法各有各的战场：
- 引用计数：适合Python、PHP这类对实时性要求高、但内存泄漏容忍度也高的脚本语言。
- 标记清除：是大多数现代JVM、V8等的基础，但必须搭配压缩或整理策略来对抗碎片。
- 分代收集：是最聪明的策略。通过把对象分成“短命”和“长命”的，把80%的GC精力花在了20%的新生代上，大大降低了系统停顿。
理解这些基础，你在分析内存泄漏时就能快速定位问题根源——到底是循环引用（引用计数问题）、还是GC停顿过长（标记清除问题）、还是对象晋升失败（分代收集问题）。希望这次梳理对你有实际帮助。