垃圾回收（GC）入门：从 “内存泄漏” 到 “自动清理” 的核心逻辑

GC核心机制解析：自动内存管理

最新推荐文章于 2025-12-10 13:40:01 发布

原创最新推荐文章于 2025-12-10 13:40:01 发布 · 663 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#jvm #java #算法

Java 进阶同时被 2 个专栏收录

60 篇文章

订阅专栏

JVM 底层原理

17 篇文章

订阅专栏

如果你写过C/C++代码，一定对手动释放内存的场景记忆犹新——用malloc申请的空间，必须记得用free回收，稍有疏忽就可能引发内存泄漏。而Java、Python、Go等语言却很少让我们操心这件事，这背后的“隐形管家”，就是垃圾回收（Garbage Collection，简称GC）。今天我们就从“内存泄漏的噩梦”说起，拆解GC的核心逻辑，搞懂它是如何实现“自动清理”的。

一、先搞懂：为什么需要GC？内存泄漏有多坑？

在聊GC之前，我们得先明确一个前提：计算机的内存是有限资源。当程序运行时，会不断创建对象、分配内存——比如Java里的new Object()、Python里的列表生成式，这些操作都会占用内存空间。

如果这些“用过的内存”不能及时回收，就会出现两种问题：

内存泄漏：程序占用的内存越来越大，却没有实际用途。比如C++中忘记释放动态分配的数组，这些“僵尸内存”会一直占用空间，直到程序退出。如果是服务器这类长期运行的程序，内存泄漏最终会导致程序崩溃，甚至拖垮整个系统。
内存溢出（OOM）：当内存泄漏积累到一定程度，或者程序申请的内存超过系统可用内存时，就会触发“内存溢出”错误，比如Java的OutOfMemoryError，这意味着程序彻底无法继续运行。

GC的核心作用，就是替代程序员完成“识别无用内存-回收内存”的工作，既避免了人为操作的疏忽，又降低了开发门槛。简单说，GC就是内存的“自动清洁工”，负责把“垃圾”清理掉，腾出空间给新的对象使用。

二、GC的核心问题：怎么判断“垃圾”？

GC工作的第一步，也是最关键的一步，是区分“有用内存”和“垃圾内存”。所谓“垃圾”，就是程序后续运行中再也用不到的对象所占用的内存。但计算机怎么知道一个对象“没用了”？行业里有两种主流判断标准：

1. 引用计数法：简单但有“短板”

这是最直观的判断方式：给每个对象分配一个“引用计数器”，每当有地方引用这个对象时，计数器加1；当引用失效时，计数器减1。当计数器的值为0时，就认为这个对象是垃圾，可以回收。

比如Python早期就用这种方式：当你执行a = [1,2,3]时，列表对象的引用计数是1；再执行b = a，引用计数变成2；当del a后，计数减为1；直到del b，计数变为0，这个列表就会被GC回收。

但引用计数法有个致命缺陷——无法解决循环引用问题。比如两个对象A和B，A引用B，B又引用A，除此之外没有其他引用。这时两者的引用计数都是1，永远不会变成0，就会成为“无法回收的垃圾”，最终导致内存泄漏。为了解决这个问题，Java、Python（后期）都放弃了纯引用计数法，转而采用“可达性分析”。

2. 可达性分析：从“根”出发找“活对象”

这是目前主流GC采用的判断方式，核心思路是：以“根对象”（Garbage Collection Roots，简称GC Roots）为起点，遍历对象之间的引用关系，所有能被遍历到的对象都是“活对象”，遍历不到的就是“垃圾”。

那么哪些对象能成为“根对象”？不同语言的定义类似，以Java为例，主要包括：

虚拟机栈（栈帧中的局部变量表）中引用的对象，比如正在执行的方法里的变量；
方法区中类静态属性引用的对象，比如static修饰的变量；
方法区中常量引用的对象，比如字符串常量池中的对象；
本地方法栈中JNI（Java Native Interface）引用的对象，也就是Java调用的C/C++代码中的变量。

举个例子：当你执行User u = new User()时，变量u在虚拟机栈中，属于GC Roots的一部分，它引用的User对象会被标记为“活对象”；当u = null后，这个User对象再也无法通过GC Roots遍历到，就会被判定为垃圾。

可达性分析完美解决了循环引用问题——即使A和B相互引用，但只要没有GC Roots指向它们，就会被判定为垃圾，从而被回收。

三、GC的工作流程：标记-清除-整理，三步搞定回收

当GC确定了“垃圾”之后，就需要执行回收操作。不同GC算法的执行细节有差异，但核心流程都围绕“标记-清除-整理”三个核心步骤展开，我们以最基础的“标记-清除算法”和优化后的“标记-复制算法”“标记-整理算法”为例，拆解这个过程。

1. 标记-清除算法：最基础但有“碎片”问题

这是GC的“鼻祖”算法，流程分为两步：

标记：通过可达性分析，标记出所有活对象；
清除：遍历内存区域，将未被标记的垃圾对象占用的内存直接释放。

这种算法的优点是简单、高效，但缺点也很明显——会产生大量内存碎片。比如内存中原本有A、B、C三个对象，回收B之后，内存中会出现一块空闲区域；如果后续需要分配一个比这块空闲区域大但比A+C总空间小的对象，就会因为没有连续的内存空间而分配失败，即使总空闲内存足够。

2. 标记-复制算法：解决碎片但浪费空间

为了解决内存碎片问题，标记-复制算法应运而生。它的核心思路是：将内存分为大小相等的两个区域，称为“From区”和“To区”，每次只使用其中一个区域（From区）。

标记：在From区中通过可达性分析标记活对象；
复制：将From区中的活对象完整复制到To区，并且按顺序排列，避免碎片；
切换：将From区和To区的角色互换，原来的To区变成新的From区，原来的From区被清空，等待下一次回收。

这种算法的优点是没有内存碎片，分配内存时只需要移动“指针”即可，效率极高。但缺点也很直接——浪费一半内存空间，因为总有一个区域是空的。不过对于“对象存活时间短”的场景（比如Java的新生代），这种算法非常合适，因为新生代的对象大多“朝生夕死”，复制的成本很低。

3. 标记-整理算法：兼顾无碎片和空间效率

标记-整理算法是为了解决标记-复制算法的空间浪费问题，主要用于“对象存活时间长”的场景（比如Java的老年代）。它的流程是：

标记：和前面两种算法一样，标记出所有活对象；
整理：将所有活对象向内存区域的一端移动，然后直接清理掉边界之外的所有垃圾内存。

这种算法既避免了内存碎片，又充分利用了内存空间，但缺点是“整理”过程需要移动大量对象，会消耗更多时间。

4. 分代收集：主流GC的“组合拳”

实际上，现代GC都不会只用一种算法，而是采用“分代收集”策略——根据对象的存活时间，将内存分为不同的区域（比如Java的新生代、老年代、永久代），针对不同区域使用不同的算法。

核心逻辑是“对象存活时间越久，越难被回收”：

新生代：对象存活时间短，大多一次GC就会被回收，采用“标记-复制算法”，效率高；
老年代：对象存活时间长，存活比例高，采用“标记-整理算法”，避免空间浪费；
永久代/元空间：存储类信息、常量等，回收频率低，采用专门的回收策略。

这种“分代收集”的思路，兼顾了回收效率和空间利用率，是目前Java HotSpot虚拟机、Go GC等主流GC的核心设计思路。

四、GC的“副作用”与优化：如何减少停顿？

虽然GC帮我们解决了内存管理的难题，但它并不是“零成本”的——GC执行时，需要暂停程序的运行（称为“Stop The World”，简称STW），否则程序不断创建对象，GC的标记结果会一直变化，无法完成回收。

早期的GC算法（比如Serial GC）会导致较长时间的STW，比如几秒甚至几十秒，这对实时性要求高的程序（比如电商支付、游戏）来说是无法接受的。为了减少STW时间，现代GC做了很多优化，核心思路是“将GC操作与程序运行并行化”：

并行GC：启动多个GC线程同时执行回收操作，加快回收速度，减少STW时间（比如Java的Parallel GC）；
并发GC：GC线程和程序线程同时运行，只在标记的“初始阶段”和“最终阶段”短暂停顿程序，大部分时间不影响程序运行（比如Java的CMS GC、G1 GC，Go的三色标记法）。

以Go的GC为例，它采用“三色标记法”实现并发回收：将对象分为白色（未标记）、灰色（待标记）、黑色（已标记），GC线程先标记灰色对象，再将其引用的对象设为灰色，同时程序线程运行时会遵守“写屏障”规则，避免新的引用关系导致标记错误。这种方式能将STW时间控制在毫秒级，甚至微秒级，极大降低了对程序的影响。

五、新手必知：即使有GC，也会内存泄漏？

看到这里，你可能会问：“有了GC，是不是就不用担心内存泄漏了？”答案是否定的。GC能回收“程序无法引用的垃圾”，但如果程序持有不必要的引用，GC就无法回收这些对象，从而导致“逻辑上的内存泄漏”。

比如以下场景，即使有GC也会出问题：

静态集合类的滥用：Java中的static List，如果不断往里面添加对象却不清理，这些对象会一直被静态变量引用，GC无法回收，最终导致内存溢出；
资源未关闭：比如数据库连接、文件流，如果不调用close()方法关闭，即使对象本身被回收，底层的资源句柄也可能无法释放，导致“资源泄漏”，间接引发内存问题；
长生命周期对象引用短生命周期对象：比如缓存系统中，用全局缓存引用临时的用户会话对象，如果会话结束后不从缓存中移除，这些对象会一直被缓存引用，无法回收。

所以，即使有GC，我们仍需要养成良好的编程习惯：及时释放不必要的引用、关闭资源、合理使用缓存等，避免“逻辑上的内存泄漏”。