22-GC Roots 详解上一篇讲到可达性分析从一组确定存活的根对象出发去遍历整张对象图。这组根对象就是GC Roots。但到底哪些对象能成为 GC Roots这并不是一句栈里的引用就能说清楚的——HotSpot 实际定义了多类根对象每一类背后都对应着 JVM 的某个内部结构。本篇将逐一拆解 GC Roots 的种类并演示如何用工具去实际观察它们。GC Roots 的种类理解 GC Roots关键在于明白一个原则GC Roots 是虚拟机规范层面上不得回收的引用来源。只要引用还存在于这些位置被引用的对象就不能被回收。HotSpot 将 GC Roots 分为以下几大类。1. 虚拟机栈中的局部变量这是最直观、也是数量最多的一类。当前所有线程的 Java 方法栈帧中局部变量表里存放的对象引用都是 GC Roots。publicvoidfoo(){ObjectlocalnewObject();// local 就是 GC Roots// 方法返回前local 指向的对象不可回收}每个栈帧的 LocalVariableTable 中类型为reference的槽位都会作为根。这也是为什么大方法里临时引用过多会增加标记开销——根越多初始标记集合越大。2. 方法区中的静态属性类的静态字段引用的对象同样属于 GC Roots。只要类本身没被卸载这些对象就一直可达。publicclassConfigHolder{// staticConfig 是 GC RootspublicstaticfinalConfigSTATIC_CONFIGloadConfig();}JDK 8 之后方法区由**元空间Metaspace**实现静态字段存储在 Class 对象关联的镜像mirror上。即使如此它们仍属于方法区层面的根。3. 方法区中的常量常量池里的引用类型常量也是 GC Roots。例如字符串常量池String Table中的String对象publicclassConstExample{// HELLO 进入字符串常量池成为 GC RootpublicstaticfinalStringGREETINGHELLO;publicvoiduse(){// 运行期 intern 的字符串也会进入常量池StringsnewString(world).intern();}}JDK 7 之后字符串常量池从永久代移到了 Java 堆中但其作为 GC Roots 的属性没有改变。4. 本地方法栈中的 JNI 引用通过 JNI 调用本地代码时本地方法栈中保存的对象引用也是 GC Roots。比如NewGlobalRef、NewLocalRef创建的引用。// JNI 代码示例JNIEXPORTvoidJNICALLJava_Cache_setHandle(JNIEnv*env,jobject this){jobject globalRef(*env)-NewGlobalRef(env,this);// globalRef 进入本地方法栈成为 GC Root// 必须显式 DeleteGlobalRef 才能被回收}这类根容易造成内存泄漏本地代码持有 Java 对象的全局引用但忘记释放对象就永远无法回收。5. Java 虚拟机内部的引用JVM 自身运行需要持有一些对象它们也是 GC Roots包括基本类型的 Class 对象Integer.class等常用的异常对象NullPointerException、OutOfMemoryError等类加载器对象JIT 编译器内部持有的对象这部分通常数量不大但不可或缺。6. 同步锁monitor持有的对象synchronized锁住的对象在锁被释放前不会被回收。因为持有锁的线程通过对象头中的 Monitor 记录与之关联。publicclassLockRoot{privatefinalObjectlocknewObject();publicvoiddoWork(){synchronized(lock){// lock 在 synchronized 块内是 GC Root// 即使没有其他引用也不会被回收waitForEvent();}}}7. JMXBean、JVMTI 等管理接口引用JVM 通过 JMX 暴露的 MBean、JVMTIJVM Tool Interface持有的对象也会作为 GC Roots。调试器、profiler 通过 JVMTI 跟踪的对象在调试/profiling 期间不会被回收这是开发期常见的对象该死却没死原因之一。全局根与局部根可以把上述 GC Roots 简单分为两类局部根随线程生灭如栈帧局部变量、JNI local ref。全局根JVM 范围共享如静态字段、常量池、JVM 内部引用、JMX 等。GC 开始时HotSpot 会遍历所有线程的栈帧、JNI 引用再扫描全局根集合形成完整的初始根集合。用 jmap 查看 GC Rootsjmap适合在 JDK 8 下使用它提供-finalizerinfo和堆直方图等视图。要查看根引用更常用的是jmap -dump导出堆转储后用 MAT 分析。# 导出堆转储jmap -dump:live,formatb,fileheap.hprofpid# live 参数会先触发一次 GC仅保留存活对象MAT 打开后在 “Leak Suspects” 或 “Histogram” 视图中可以查看任意对象的“GC Roots”路径它会告诉你这个对象是从哪条引用链到达的。JDK 9 推荐改用jcmdjcmdpidGC.heap_dump heap.hprofjmap -histo 观察对象统计# 按对象大小排序jmap-histopid|head-20# 只看存活对象会触发 GCjmap-histo:livepid|head-20输出示例num #instances #bytes class name ---------------------------------------------- 1: 245632 19705632 [C 2: 89324 7145920 java.lang.String 3: 45211 3616880 java.util.HashMap$Node虽然这只给出直方图不直接显示根但配合live参数可以快速验证哪些对象被某种根引用所持有。用 Arthas 查看 GC RootsArthas 是阿里开源的诊断工具提供了heapdump命令与jmap类似# 下载并启动 arthasjava-jararthas-boot.jarpid# 导出堆转储[arthas1234]$ heapdump--live/tmp/heap.hprof# 查看对象大小[arthas1234]$ dashboardArthas 的heapdump同样会生成 hprof 文件可丢给 MAT 分析。它的优势在于无需提前安装、可 attach 到运行进程上。用 Arthas 观察静态字段根Arthas 的ognl命令可以直接读取类的静态字段配合heapdump能快速定位为什么这个对象不释放# 查看某静态字段引用的对象[arthas1234]$ ognlcom.example.ConfigHolderSTATIC_CONFIGMAT 中的 GC Roots 分类打开 hprof 后在 MAT 中查看某个对象的 “Path To GC Roots”会看到根被标注为以下类型之一Java local栈帧局部变量Static field静态字段JNI globalJNI 全局引用JNI localJNI 局部引用Monitor被 synchronized 持有Java frame栈帧旧分类System class系统类加载的静态字段Thread线程对象本身Busy Monitor被某个线程持有锁的对象这些分类与上文列出的 GC Roots 种类一一对应。代码示例观察 GC Roots 的引用链下面通过一段代码构造不同类型的 GC Roots再用堆转储观察引用链/** * 构造多种 GC Roots便于在 MAT 中观察 * 适用 JDK 8/11/17 */publicclassGcRootsDemo{// 1. 静态字段根privatestaticfinalObjectSTATIC_ROOTnewBigObject(static);// 2. 常量根publicstaticfinalStringCONST_ROOTGC_ROOT_CONSTANT;// 3. 同步锁根privatestaticfinalObjectLOCKnewBigObject(lock);publicstaticvoidmain(String[]args)throwsException{// 4. 局部变量根BigObjectlocalnewBigObject(local);// 让 LOCK 一直被持有newThread(()-{synchronized(LOCK){try{Thread.sleep(Long.MAX_VALUE);}catch(InterruptedExceptione){Thread.currentThread().interrupt();}}},lock-holder).start();// 5. JNI 全局引用模拟通过 Thread 持有ThreadholdernewThread(()-{ObjectjniLikenewBigObject(jni-like);try{Thread.sleep(Long.MAX_VALUE);}catch(InterruptedExceptione){Thread.currentThread().interrupt();}},jni-holder);holder.setDaemon(true);holder.start();// 留出时间导出堆Thread.sleep(60_000);}staticclassBigObject{privatefinalbyte[]datanewbyte[512*1024];privatefinalStringtag;BigObject(Stringtag){this.tagtag;}}}用jcmd pid GC.heap_dump heap.hprof导出后在 MAT 中打开按BigObject类型过滤逐一查看每个实例的 “Path To GC Roots”static标签的对象 →Static fieldGcRootsDemo.STATIC_ROOTlock标签的对象 →Busy Monitorlock-holder线程持有local标签的对象 →Java localmain线程栈帧jni-like标签的对象 →Threadjni-holder线程引用这种实操能让你对GC Roots 是什么形成直觉。实践要点1. 静态集合是常见的隐性根static MapString, Object CACHE new HashMap();这种写法在工程里非常常见。如果只是put不remove缓存中的对象就会因静态字段根而永生。建议用WeakHashMap或带 TTL 的缓存替代。2. ThreadLocal 与 GC RootsThreadLocal的值实际存储在线程对象的ThreadLocalMap中而线程对象是 GC Root。所以线程不死ThreadLocal 中的对象不回收。线程池场景下尤其要主动remove()。3. JNI 泄漏最难排查本地代码持有全局引用未释放导致的泄漏MAT 中会看到根类型是JNI global。这种泄漏需要回到 C/C 代码侧审计NewGlobalRef/DeleteGlobalRef配对。4. 调试器/profiler 会改变可达性线上用调试器 attach 时被调试器观察的对象会成为 GC Roots可能掩盖内存泄漏。排查内存问题应尽量用离线堆转储而不是在线 attach。5. 元空间类卸载静态字段成为根的前提是类本身还活着。一旦类被卸载其静态字段引用的对象就不再是根。旧版本 JDK 中自定义类加载器泄漏常因类加载器间的引用链导致类无法卸载引起。小结GC Roots 包括虚拟机栈局部变量、方法区静态属性、方法区常量、本地方法栈 JNI 引用、JVM 内部引用、同步锁持有对象、JMX/JVMTI 引用等。局部根随线程生灭全局根 JVM 范围共享。jmap/jcmd导出堆转储后用 MAT 观察 “Path To GC Roots”可看到根的类型分类。工程中最常见的隐性根是静态集合和 ThreadLocal应作为代码审查的重点。JNI 全局引用、调试器 attach 是对象该死不死的隐蔽原因。下一篇我们继续聚焦引用这个主题深入 Java 的四种引用类型——强、软、弱、虚——它们让你可以在GC Roots 可达之外更精细地控制对象的生命周期。更多内容JVM调优实战
