1.虚拟机栈（本地变量表）引用的对象html
2.方法区静态属性引用的对象
3.方法区常量引用的对象
4.本地方法栈JNI（通常指naive方法）中引用的对象
常说的GC(Garbage Collector) roots，特指的是垃圾收集器（Garbage Collector）的对象，GC会收集那些不是GC roots且没有被GC roots引用的对象。java
一个对象能够属于多个root，GC root有几下种：算法
- Class - 由系统类加载器(system class loader)加载的对象，这些类是不可以被回收的，他们能够以静态字段的方式保存持有其它对象。咱们须要注意的一点就是，经过用户自定义的类加载器加载的类，除非相应的
java.lang.Class实例以其它的某种（或多种）方式成为roots，不然它们并非roots，. - Thread - 活着的线程
- Stack Local - Java方法的local变量或参数
- JNI Local - JNI方法的local变量或参数
- JNI Global - 全局JNI引用
- Monitor Used - 用于同步的监控对象
- Held by JVM - 用于JVM特殊目的由GC保留的对象，但实际上这个与JVM的实现是有关的。可能已知的一些类型是：系统类加载器、一些JVM知道的重要的异常类、一些用于处理异常的预分配对象以及一些自定义的类加载器等。然而，JVM并无为这些对象提供其它的信息，所以就只有留给分析分员去肯定哪些是属于"JVM持有"的了。
如下是一张由Java Profiler的标示出哪些是GC roots的示例图：bootstrap
做者：RednaxelaFX
连接：https://www.zhihu.com/question/53613423/answer/135743258
来源：知乎
著做权归做者全部，转载请联系做者得到受权。数据结构
以前看深刻理解JVM这本书，对里面的GC ROOT的真实含义不是太清楚，网上查了一大堆资料都没有说的很清楚，下面这是从知乎大神上看到的，这里面记录一下，和你们一块儿学习并发
所谓“GC roots”，或者说tracing GC的“根集合”，就是一组必须活跃的引用。
例如说，这些引用可能包括：
Tracing GC的根本思路就是：给定一个集合的引用做为根出发，经过引用关系遍历对象图，能被遍历到的（可到达的）对象就被断定为存活，其他对象（也就是没有被遍历到的）就天然被断定为死亡。注意再注意：tracing GC的本质是经过找出全部活对象来把其他空间认定为“无用”，而不是找出全部死掉的对象并回收它们占用的空间。
GC roots这组引用是tracing GC的起点。要实现语义正确的tracing GC，就必需要能完整枚举出全部的GC roots，不然就可能会漏扫描应该存活的对象，致使GC错误回收了这些被漏扫的活对象。
这就像任何递归定义的关系同样，若是只定义了递推项而不定义初始项的话，关系就没法成立——无从开始；而若是初始项定义漏了内容的话，递推出去也会漏内容。
那么分代式GC对GC roots的定义有什么影响呢？
答案是：分代式GC是一种部分收集（partial collection）的作法。在执行部分收集时，从GC堆的非收集部分指向收集部分的引用，也必须做为GC roots的一部分。
具体到分两代的分代式GC来讲，若是第0代叫作young gen，第1代叫作old gen，那么若是有minor GC / young GC只收集young gen里的垃圾，则young gen属于“收集部分”，而old gen属于“非收集部分”，那么从old gen指向young gen的引用就必须做为minor GC / young GC的GC roots的一部分。
继续具体到HotSpot VM里的分两代式GC来讲，除了old gen到young gen的引用以外，有些带有弱引用语义的结构，例如说记录全部当前被加载的类的SystemDictionary、记录字符串常量引用的StringTable等，在young GC时必需要做为strong GC roots，而在收集整堆的full GC时则不会被看做strong GC roots。
换句话说，young GC比full GC的GC roots还要更大一些。若是不能理解这个道理，那整个讨论也就无从谈起了。
例如说，这些引用可能包括：
- 全部Java线程当前活跃的栈帧里指向GC堆里的对象的引用；换句话说，当前全部正在被调用的方法的引用类型的参数/局部变量/临时值。
- VM的一些静态数据结构里指向GC堆里的对象的引用，例如说HotSpot VM里的Universe里有不少这样的引用。
- JNI handles，包括global handles和local handles
- （看状况）全部当前被加载的Java类
- （看状况）Java类的引用类型静态变量
- （看状况）Java类的运行时常量池里的引用类型常量（String或Class类型）
- （看状况）String常量池（StringTable）里的引用
Tracing GC的根本思路就是：给定一个集合的引用做为根出发，经过引用关系遍历对象图，能被遍历到的（可到达的）对象就被断定为存活，其他对象（也就是没有被遍历到的）就天然被断定为死亡。注意再注意：tracing GC的本质是经过找出全部活对象来把其他空间认定为“无用”，而不是找出全部死掉的对象并回收它们占用的空间。
GC roots这组引用是tracing GC的起点。要实现语义正确的tracing GC，就必需要能完整枚举出全部的GC roots，不然就可能会漏扫描应该存活的对象，致使GC错误回收了这些被漏扫的活对象。
这就像任何递归定义的关系同样，若是只定义了递推项而不定义初始项的话，关系就没法成立——无从开始；而若是初始项定义漏了内容的话，递推出去也会漏内容。
那么分代式GC对GC roots的定义有什么影响呢？
答案是：分代式GC是一种部分收集（partial collection）的作法。在执行部分收集时，从GC堆的非收集部分指向收集部分的引用，也必须做为GC roots的一部分。
具体到分两代的分代式GC来讲，若是第0代叫作young gen，第1代叫作old gen，那么若是有minor GC / young GC只收集young gen里的垃圾，则young gen属于“收集部分”，而old gen属于“非收集部分”，那么从old gen指向young gen的引用就必须做为minor GC / young GC的GC roots的一部分。
继续具体到HotSpot VM里的分两代式GC来讲，除了old gen到young gen的引用以外，有些带有弱引用语义的结构，例如说记录全部当前被加载的类的SystemDictionary、记录字符串常量引用的StringTable等，在young GC时必需要做为strong GC roots，而在收集整堆的full GC时则不会被看做strong GC roots。
换句话说，young GC比full GC的GC roots还要更大一些。若是不能理解这个道理，那整个讨论也就无从谈起了。
Garbage Collection Roots A garbage collection root is an object that is accessible from outside the heap. The following reasons make an object a GC root: System Class Class loaded by bootstrap/system class loader. For example, everything from the rt.jar like java.util.* . JNI Local Local variable in native code, such as user defined JNI code or JVM internal code. JNI Global Global variable in native code, such as user defined JNI code or JVM internal code. Thread Block Object referred to from a currently active thread block. Thread A started, but not stopped, thread. Busy Monitor Everything that has called wait() or notify() or that is synchronized. For example, by calling synchronized(Object) or by entering a synchronized method. Static method means class, non-static method means object. Java Local Local variable. For example, input parameters or locally created objects of methods that are still in the stack of a thread. Native Stack In or out parameters in native code, such as user defined JNI code or JVM internal code. This is often the case as many methods have native parts and the objects handled as method parameters become GC roots. For example, parameters used for file/network I/O methods or reflection. Finalizable An object which is in a queue awaiting its finalizer to be run. Unfinalized An object which has a finalize method, but has not been finalized and is not yet on the finalizer queue. Unreachable An object which is unreachable from any other root, but has been marked as a root by MAT to retain objects which otherwise would not be included in the analysis. Java Stack Frame A Java stack frame, holding local variables. Only generated when the dump is parsed with the preference set to treat Java stack frames as objects. Unknown An object of unknown root type. Some dumps, such as IBM Portable Heap Dump files, do not have root information. For these dumps the MAT parser marks objects which are have no inbound references or are unreachable from any other root as roots of this type. This ensures that MAT retains all the objects in the dump 做者：秦汉邮侠 连接：https://www.jianshu.com/p/f4ff9fcc0759 來源：简书 简书著做权归做者全部，任何形式的转载都请联系做者得到受权并注明出处。
参考：less
https://www.jianshu.com/p/f4ff9fcc0759jvm
原文地址：https://www.cnblogs.com/FlyAway2013/p/10240919.html