GCRoots

所谓"GC roots", 或者说tracing GC的"根集合", 就是一组必须活跃的引用.
例如说, 这些引用可能包括:

所有Java线程当前活跃的栈帧里指向GC堆里的对象的引用; 换句话说, 当前所有正在被调用的方法的引用类型的参数/局部变量/临时值.
VM的一些静态数据结构里指向GC堆里的对象的引用, 例如说HotSpot VM里的Universe里有很多这样的引用.
JNI handles, 包括global handles和local handles
所有当前被加载的Java类
Java类的引用类型静态变量
Java类的运行时常量池里的引用类型常量(String或Class类型)
String常量池(String Table)里的引用

注意, 是一组必须活跃的引用, 不是对象
Tracing GC的根本思路就是: 给定一个集合的引用作为根出发, 通过引用关系遍历对象图, 能被遍历到的(可达到的)对象就判定为存活, 其余对象(也就是没有被遍历到的)就自然被判定为死亡. 注意再注意: tracing GC的本质是通过找出所有活对象来把其余空间认定为"无用", 而不是找出所有死掉的对象并回收它们占用的空间.
GC Roots这组引用是tracing GC的起点. 要实现语义正确的tracing GC, 就必须要能完整枚举出所有的GC roots, 否则就可能会漏扫描应该存活的对象, 导致GC错误回收了这些被漏扫的活对象.

目前主流的虚拟机都是采用GC Roots Tracing算法, 比如Sun的Hotspot虚拟机便是采用该算法, 该算法的核心算法是从GC Roots对象作为起始点, 利用数学中图论知识, 图中可达对象便是存活对象, 而不可达对象则是需要回收的垃圾内存, 这里涉及到两个概念: GC Roots, 可达性.

所谓“GC roots”，或者说tracing GC的“根集合”，就是一组必须活跃的引用。

GC Roots的节点: 全局性的引用(常量或静态属性)、执行上下文(例如栈帧中的局部变量表中)
可作为GC Roots的对象:

// Class loaded by bootstrap/system class loader. For example, everything from the rt.jar like java.util.* .
1.System Class
// Local variable in native code, such as user defined JNI code or JVM internal code.
2.JNI Local
// Global variable in native code, such as user defined JNI code or JVM internal code.
3.JNI Global
// Object referred to from a currently active thread block.
4.Thread Block
// A started, but not stopped, thread.
Thread
// 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.
5.Busy Monitor---用于同步的监控对象
// Local variable. For example, input parameters or locally created objects of methods that are still in the stack of a thread.
6.Java Local
// 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.
7.Native Stack
// An object which is in a queue awaiting its finalizer to be run.
8.Finalizable
// An object which has a finalize method, but has not been finalized and is not yet on the finalizer queue.
9.Unfinalized
// 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.
10.Unreachable
// 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.
11.Java Stack Frame
// 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.
12.Unknown

对于HotSpot VM的GC而言, 不同的GC策略对于的GC Roots基本一致, 对于Parallel Scavenge, 实现上定义了一个较为明确的RootType枚举类型

enum RootType {
    universe                  = 1,
    jni_handles               = 2,
    threads                   = 3,
    object_synchronizer       = 4,
    flat_profiler             = 5,
    system_dictionary         = 6,
    class_loader_data         = 7,
    management                = 8,
    jvmti                     = 9,
    code_cache                = 10
}

关于可达性的对象, 便是能与GC Roots构成连通的对象, 如下图:

根搜索算法的基本思路就是通过一系列名为"GC Roots"的对象作为起始点, 从这些节点开始向下搜索, 搜索所走过的路径称为引用链(Reference Chain), 当一个对象到GC Roots没有任何引用链相连时, 则证明此对象是不可用的.

从上图, reference1、reference2、reference3都是GC Roots, 可以看出:
reference1 -> 对象实例1;
reference2 -> 对象实例2;
reference3 -> 对象实例3;
reference3 -> 对象实例4 -> 对象实例6;
可以得出对象实例1、2、4、6都具有GC Roots可达性, 也就是存活对象, 不能被GC回收的对象.
而对于对象实例3、5虽然直接连通, 但并没有任何一个GC Roots与之相连, 这便是GC Roots不可达的对象, 也就是GC需要回收的垃圾对象.