GC Roots是JVM在GC时认定“必须存活”的对象引用，包括虚拟机栈中局部变量引用的对象、本地方法栈中JNI引用的对象、方法区中类静态属性和常量引用的对象、以及JVM内部特殊对象；其本质是当前时刻强持有且需保障存活的引用。
Java虚拟机判断对象是否存活，依赖的是可达性分析算法，其核心是找出一组被称为GC Roots的起点对象。从这些根出发，沿着引用链向下搜索，能被触及的对象视为“存活”，其余则可能被回收。
哪些对象可以作为GC Roots？
GC Roots不是固定不变的类或实例，而是在特定时刻被JVM认定为“必须存活”的对象引用**。主要包括以下几类：
- 虚拟机栈（栈帧中的局部变量表）中引用的对象：每个线程的栈帧里，正在执行的方法所持有的局部变量（包括参数、临时变量等）如果指向某个对象，该对象就是GC Root。
- 本地方法栈中JNI（即Native方法）引用的对象：Java调用C/C++代码时，通过JNI创建的全局引用（Global Reference）或局部引用（Local Reference）若未被显式释放，对应Java对象也会被视作Root。
- 方法区中类静态属性引用的对象：例如 public static Object cache = new Object(); 中的 cache 所指对象。
- 方法区中常量引用的对象：比如字符串常量池（String Table）里的字符串对象（注意：JDK 7+ 字符串常量池已移到堆中，但仍属于GC Roots范畴）；还有 public static final String NAME = "hello"; 这类编译期确定的常量所引用的对象。
- Java虚拟机内部的特殊对象：如基本类型的Class对象、一些关键系统类（如 java.lang.Object）、异常处理对象（如正在抛出的异常实例）、同步锁持有的对象（synchronized块监视器）等。
特别注意：不是所有静态变量都天然等于GC Root
只有被加载且初始化完成的类中，其静态字段实际持有非null引用时，该引用才构成GC Root。例如：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 类尚未初始化（如还未触发
），静态字段还是默认值（null），不构成Root。 - 静态字段被显式赋值为null，引用断开，对象就可能被回收（前提是无其他路径可达）。
- 使用弱引用（WeakReference）、软引用（SoftReference）或虚引用（PhantomReference）持有的对象，本身不作为GC Roots，也不阻止被回收（行为由引用类型决定）。
GC Roots是动态快照，不是静态列表
JVM在每次GC前会暂停所有应用线程（STW），然后在那一刻抓取所有活跃线程的栈状态、方法区数据等，构建出瞬时的GC Roots集合。这意味着：
立即学习“Java免费学习笔记（深入）”；
- 同一个对象，在不同GC时刻可能有时是Root，有时不是（比如局部变量作用域结束，引用消失）。
- GC Roots本身也可能被回收——比如一个线程结束，其栈帧销毁，原来栈里的引用就不再有效。
- 没有“永久GC Root”，一切以当前安全点（Safepoint）采集到的引用为准。
基本上就这些。理解GC Roots的关键，不在于死记条目，而在于抓住本质：谁在当前时刻“强持有”着对象，且这种持有是JVM必须保障其存活的。搞清这点，就能自然推导出哪些算Root，哪些不算。
