王少冬说到GC Root节点，很多Java开发者的第一反应可能是：这又是哪个系统权限的root？别搞混了，这里的GC Root是JVM垃圾回收体系里一个非常基础、但特别容易被忽略的概念。我做JVM性能调优和线上问题排查这些年，几乎每一次内存泄漏、每一次Full GC频繁触发，最后都得回到GC Roots上找答案。如果你只会看jstat输出、看GC日志里的停顿时间，却搞不清楚对象到底是怎么被“标记存活”的，那排查问题的时候就会一直隔靴搔痒。
这篇文章我想把GC Root节点掰开揉碎讲清楚：它到底是什么、哪些东西能成为根、栈上和堆里的根有什么区别、静态变量为什么是内存泄漏的重灾区，以及拿到一个堆转储文件之后，怎么用MAT这类工具顺着GC Roots把泄漏源揪出来。适合正在做Java服务端开发、准备JVM调优面试，或者已经被线上OOM折磨过几轮的工程师参考。
1. GC Root节点到底是什么：从一次线上OOM说起
2018年我负责过一个订单中台服务，平时运行得很稳，结果某天大促预热刚开始，线上直接OOM，而且不是那种能自动恢复的堆溢出，是持续性的内存上涨。dump完堆之后一分析，发现订单对象占了70%以上的堆，但它们明明早该被处理完了。当时我就顺着对象的引用链往上追，最终发现是历史订单状态机里维护了一个静态的“待重试任务队列”，这个队列把所有还没走到终态的订单对象全都引用住了。队列本身被静态字段持有，静态字段就是GC Roots，于是这些订单对象永远不会被回收。这就是GC Roots在实际问题里的典型表现：不直接导致崩溃，但会让对象失去被回收的机会，慢慢把堆撑爆。
1.1 可达性分析算法的核心逻辑
主流的JVM（HotSpot）判断对象是否可回收，不是我们初学者时听说的“引用计数”，而是可达性分析。所谓可达性分析，就是从一个固定的起点集合出发，沿着引用关系往下走，能走到的对象标记为“存活”，走不到的对象判定为“可回收”。这个起点集合，就是GC Roots。
这里有个关键点要理解：JVM不是遍历堆里每一个对象去问“你有没有被别人引用”，那样O(n)扫描太重了。它只从少数的根出发做图遍历，遍历到的是存活对象，剩下的全是垃圾。这个思路有点像在一栋楼里找还有没有人：你不需要敲开每一扇门问，你只要看门禁系统里谁登记了“我还在”，没登记的默认就是离开了。GC Roots就是那个门禁系统里的登记名单。
所以GC Roots的定义可以非常朴素：能让JVM认定“从根上还能到达”的引用入口。任何从这些入口出发能触达的对象，都会被标记为存活；触达不到的，不管它曾经多重要，这一轮GC里就会变成垃圾。
1.2 GC Roots的合法来源有哪些
HotSpot规范里，GC Roots大致包含以下几类：
| 来源 | 说明 | 举例 |
|---|---|---|
| 栈帧中的局部变量 | 正在执行的方法里声明的局部变量持有的引用 | Order order = new Order(); 中的 order |
| 操作数栈中的引用 | 当前正在计算的中间结果持有的引用 | 方法调用参数传了一半时的引用 |
| 静态字段 | 类的静态属性持有的引用 | private static List<Task> queue |
| JNI引用 | JNI全局引用、局部引用 | 调用Native层时传过去的对象 |
| 活跃线程 | 线程对象本身以及线程持有的引用 | Thread对象、ThreadLocal值 |
| 被synchronized锁定的对象 | 当前正在作为monitor的对象 | synchronized(obj) 里的obj |
| JVM内部引用 | 系统类加载器、基本类型Class对象等 | String.class、ClassLoader |
这些来源的共同点是：它们都是“从JVM外部或者从JVM运行环境里可以直接访问到的入口”。正因如此，JVM认为它们肯定不能被回收，必须作为遍历的起点。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 栈上的GC Roots最容易被低估
很多人一聊GC Roots就只知道静态变量，但实际上，日常代码里绝大多数对象的存活判断，都来自线程栈。你方法里new出来的对象，第一个持有它的就是栈帧里的局部变量表。这里面的门道非常多，而且很多坑不是看理论能看出来的。
2.1 局部变量表与操作数栈中的引用
JVM是基于栈的虚拟机，每个线程在执行方法时都会创建一个栈帧，栈帧里有局部变量表和操作数栈。你可以把局部变量表理解成方法内部的“工作台”，这个工作台上放着基本类型和对象引用；操作数栈则是计算过程中的“草稿纸”，比如你要调用另一个方法、