深入理解 GC 根对象：哪些对象永远不会被回收？

GC根对象详解：哪些对象不被回收？

原创于 2025-12-10 09:13:36 发布 · 432 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#jvm #java

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

53 篇文章

订阅专栏

JVM 底层原理

10 篇文章

订阅专栏

在Java、C#等托管语言的内存管理体系中，垃圾回收（Garbage Collection，GC）是保障程序稳定运行的核心机制。它如同一位“内存清洁工”，自动识别并回收那些不再被使用的对象，避免内存泄漏和溢出。但GC并非“一刀切”地回收所有无关联对象，其中存在一类特殊的对象——GC根对象（GC Roots），它们是GC判断对象是否存活的“基准线”，永远不会被回收。今天，我们就来深入剖析GC根对象的本质，搞清楚到底哪些对象能被“特殊优待”。

一、先搞懂：GC 如何判断对象“该回收”？

在讨论根对象之前，我们必须先明确GC的核心工作逻辑。GC判断一个对象是否需要回收，核心依据是“可达性分析”：以某些特殊对象为起点（即GC根对象），向下遍历对象的引用链。如果一个对象能通过任意一条引用链追溯到GC根对象，说明它仍在被程序使用，属于“存活对象”；反之，若无法追溯到任何GC根对象，则意味着它已失去使用价值，会被标记为“垃圾对象”，等待后续回收。

简单来说，GC根对象就是可达性分析的“起点集合”，是整个引用网络的“锚点”。没有这些锚点，GC将无法判断任何对象的存活状态，内存管理也就无从谈起。

二、核心答案：哪些对象是 GC 根对象？

不同编程语言的GC实现细节略有差异，但GC根对象的核心类型基本一致。以应用最广泛的Java为例，GC根对象主要包括以下几类，每一类都对应着程序运行的关键场景。

1. 虚拟机栈（线程栈）中的局部变量

虚拟机栈是线程私有的，它记录了线程执行过程中每个方法的局部变量表。其中存储的对象引用，是最常见的GC根对象。因为这些局部变量直接对应着当前正在执行的代码逻辑，一旦方法正在运行，这些引用指向的对象必然处于“被使用”状态。

举个例子：当我们在方法中创建一个User对象并赋值给局部变量user时，user就会被存入当前线程栈的局部变量表中，成为GC根对象的一部分。只要这个方法还在执行，user指向的User对象就会通过引用链与根对象相连，绝对不会被GC回收。只有当方法执行完毕，局部变量表中的这个引用被清空，该User对象才可能失去可达性。

2. 方法区中的静态变量和常量引用

方法区（元空间）用于存储类的结构信息，包括静态变量（static修饰）和常量（final修饰）。这些变量的生命周期与类绑定——只要类没有被虚拟机卸载，它们指向的对象就会一直被根对象“锚定”，无法被回收。

静态变量：比如一个工具类Config中有一个静态变量static DatabaseConnection conn，它指向的数据库连接对象，会因为conn是静态变量而成为GC根对象的关联对象。除非Config类被卸载（这种情况在常规应用中极少发生），否则这个连接对象永远不会被回收，这也是为什么静态变量容易引发内存泄漏的原因之一。
常量：常量池中的对象引用同样属于GC根对象。例如public static final String APP_NAME = "MyApp"，这里的字符串对象“MyApp”会被常量引用关联，只要类存在，它就不会被回收。

3. 本地方法栈中的JNI引用

本地方法栈与虚拟机栈类似，但其服务的是Native方法（由C/C++实现的方法）。当Java程序调用Native方法时，Native代码可能会创建对象并通过JNI（Java Native Interface）将对象引用存入本地方法栈中。这些JNI引用同样会被GC识别为根对象，其指向的对象只要引用存在，就不会被回收。

比如在使用Java调用本地绘图库时，本地代码创建的绘图上下文对象，通过JNI引用关联到Java层，这个绘图上下文对象就会因JNI引用成为根对象的关联对象，确保在绘图过程中不会被GC意外回收。

4. 活跃线程对象本身

正在运行的线程（活跃线程）本身也是GC根对象。因为线程是程序执行的基本单元，只要线程还在存活（未终止），它所关联的资源（如线程的栈帧、局部变量等）都必须保持可用，所以线程对象本身会被GC作为根对象对待，其引用的所有对象也会被纳入可达性分析的范围。

即使线程处于阻塞状态（如等待锁、休眠），它依然属于活跃线程，不会被GC回收。只有当线程执行完毕或被中断并彻底终止后，线程对象才可能失去根对象的身份。

5. 被虚拟机内部引用的对象

Java虚拟机在运行过程中，自身也会维护一些内部对象，这些对象同样是GC根对象。例如：

用于异常处理的对象（如OutOfMemoryError对象）；
虚拟机的类加载器对象；
正在被JVM执行的同步锁对象（如被synchronized关键字锁定的对象）；
GC自身的一些管理对象（如标记阶段使用的标记栈）。

这些对象是虚拟机正常运行的基础，GC会自动将它们标记为根对象，确保其不会被误回收。

6. 其他特殊场景的根对象

除了上述核心类型，在一些特殊场景下，某些对象也会被临时纳入GC根对象的范围，例如：

JVM参数指定的引用：通过-Xrs等参数指定的需要保留的对象引用；
调试器关联的对象：在使用IDE调试程序时，调试器为了跟踪对象状态，会将被调试的对象引用作为根对象；
内存泄漏检测工具的引用：类似MAT（Memory Analyzer Tool）这样的工具，在分析内存时也会临时将某些对象标记为根对象。

三、关键提醒：GC根对象不是“永远存活”，而是“回收的基准”

这里需要澄清一个常见的误解：说GC根对象“永远不会被回收”，并非指这些对象的生命周期是“永久”的，而是指它们是GC判断其他对象是否存活的“基准”——GC不会主动去回收根对象本身，除非根对象失去了其“根”的身份。

例如，线程对象作为根对象，当线程终止后，它就不再是活跃线程，自然会失去根对象的身份，最终可能被GC回收；静态变量作为根对象的关联者，当类被卸载后，静态变量也会被清空，其指向的对象也就可能失去可达性。

换句话说，GC根对象的“特殊地位”是动态的，会随着程序的运行状态变化而变化，但在其作为根对象的存续期间，它们以及通过引用链关联的对象，都能得到GC的“保护”。

四、实践意义：理解根对象，轻松排查内存泄漏

深入理解GC根对象，对排查内存泄漏问题至关重要。内存泄漏的本质，就是某些本应被回收的对象，意外地通过一条引用链关联到了GC根对象，导致无法被回收。

例如，我们在开发中经常遇到的“静态集合内存泄漏”：一个静态List<User>集合，不断往里面添加对象，但从未清理。由于List是静态变量（属于GC根对象关联者），它里面的所有User对象都会通过List与根对象相连，即使这些User对象已经不再被业务逻辑使用，也永远不会被GC回收，最终导致内存不断增长，引发OOM。

当我们使用MAT等工具分析内存泄漏时，核心操作就是“追溯垃圾对象的引用链”，找到它最终关联到哪个GC根对象——这个根对象往往就是内存泄漏的“罪魁祸首”（如静态变量、未关闭的线程等）。