Java垃圾回收判断哪些对象需要被回收有两种方法，引用计数法和可达性分析算法。其中，可达性分析算法使用通过一系列的称为 "GC Roots" 的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的。

什么是GC Roots

在Java语言中，"GC roots", 或者说tracing GC的"根集合", 是一组必须活跃的引用。可作为 GC Roots 的对象包括下面几种：

1. 在虚拟机栈（栈帧中的本地变量表）中引用的对象，譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。
2. 在方法区中类静态属性引用的对象，譬如Java类的引用类型静态变量。
3. 在方法区中常量引用的对象，譬如字符串常量池（String Table）里的引用。
4. 本地方法栈中 JNI（Native方法）引用的对象
5. Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象（比如NullPointExcepiton、OutOfMemoryError）等，还有系统类加载器。

6. 所有被同步锁（synchronized关键字）持有的对象。

7. 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

8. 根据用户所选用的垃圾收集器以及当前回收的内存区域不 同，“临时性”地加入的其他对象。

部分示例如下：

public class Test{
    public static  void main(String[] args) {
	     Test a = new Test();
	     a = null;
    }
}
//a是栈帧中的本地变量,a就是GC Root,由于a=null,a与new Test()对象断开了链接,所以对象会被回收。


public class Test{
    public static Test r;
    public static void main(String[] args){
       Test a=new Test();
       a.r=new Test(); //r赋值变量的引用
       a=null;  //a被回收
    }
}
//栈帧中的本地变量a=null,由于a断开了与GC Root对象(a对象)的联系,所以a对象会被回收。
//由于给Test的成员变量r赋值了变量的引用,并且r成员变量是静态的,所以r就是一个GC Root对象,
//所以r指向的对象不会被回收。


public class Rumenz{
    public static final Rumenz r=new Rumenz();
    public static void main(String[] args){
       Rumenz a=new Rumenz();
       a=null;
    }
}
//常量r引用的对象不会因为a引用的对象的回收而被回收。


JNIEXPORT void JNICALL Java_com_pecuyu_jnirefdemo_MainActivity_newStringNative(JNIEnv *env, jobject instance，jstring jmsg) {
...
   // 缓存String的class
   jclass jc = (*env)->FindClass(env, STRING_PATH);
}

GC Roots的作用机制

Tracing GC的根本思路是: 给定一个集合的引用作为根出发, 通过引用关系遍历对象图, 能被遍历到的(可达到的)对象就判定为存活, 其余对象(也就是没有被遍历到的)就自然被判定为死亡。注意再注意: tracing GC的本质是通过找出所有活对象来把其余空间认定为"无用", 而不是找出所有死掉的对象并回收它们占用的空间。

GC Roots这组引用是tracing GC的起点。要实现语义正确的tracing GC, 就必须要能完整枚举出所有的GC roots, 否则就可能会漏扫描应该存活的对象, 导致GC错误回收了这些被漏扫的活对象。

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

GC 管理的区域是Java堆，虚拟机栈、方法区和本地方法栈不被 GC 所管理，因此选用这些区域内引用的对象作为 GC Roots，是不会被 GC 所回收的。其中虚拟机栈和本地方法栈都是线程私有的内存区域，只要线程没有终止，就能确保它们中引用的对象的存活。而方法区中类静态属性引用的对象是显然存活的。常量引用的对象在当前可能存活，因此，也可能是 GC roots 的一部分。

对于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需要回收的垃圾对象。

不可达的对象将暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：

1. 如果对象在进行可达性分析后发现没有与 GC Roots 相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finalize() 方法（3），又必要就执行，无必要直接二次标记（2）。
2. 当对象没有覆盖 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行finalize() 方法”，直接进行第二次标记。
3. 如果这个对象被判定为有必要执行 finalize() 方法，那么这个对象将会放置在一个叫做 F-Queue 的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的 Finalizer 线程去执行它。

这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束，因为如果一个对象在 finalize() 方法中执行缓慢，将很可能会一直阻塞 F-Queue 队列，甚至导致整个内存回收系统崩溃。

finalize()方法的执行过程：当对象变成(GC Roots)不可达时，GC会判断该对象是否覆盖了finalize方法，若未覆盖，则直接将其回收。否则，若对象未执行过finalize方法，将其放入F-Queue队列，由一低优先级线程执行该队列中对象的finalize方法。执行finalize方法完毕后，GC会再次判断该对象是否可达，若不可达，则进行回收，否则，对象“复活”。

对象可由两种状态，涉及到两类状态空间，一是终结状态空间 F = {unfinalized, finalizable, finalized}；二是可达状态空间 R = {reachable, finalizer-reachable, unreachable}。各状态含义如下：

• unfinalized: 新建对象会先进入此状态，GC并未准备执行其finalize方法，因该对象是可达的
• finalizable: 表示GC可对该对象执行finalize方法，GC已检测到该对象不可达。正如前面所述，GC通过F-Queue队列和一专用线程完成finalize的执行
• finalized: 表示GC已经对该对象执行过finalize方法
• reachable: 表示GC Roots引用可达
• finalizer-reachable(f-reachable)：表示不是reachable，但可通过某个finalizable对象可达
• unreachable：对象不可通过上面两种途径可达。

以下是具体的执行过程：

1. 新建对象首先处于[reachable, unfinalized]状态(A)
2. 随着程序的运行，一些引用关系会消失，导致状态变迁，从reachable状态变迁到f-reachable(B, C, D)或unreachable(E, F)状态
3. 若JVM检测到处于unfinalized状态的对象变成f-reachable或unreachable，JVM会将其标记为finalizable状态(G,H)。若对象原处于[unreachable, unfinalized]状态，则同时将其标记为f-reachable(H)。
4. 在某个时刻，JVM取出某个finalizable对象，将其标记为finalized并在某个线程中执行其finalize方法。由于是在活动线程中引用了该对象，该对象将变迁到(reachable, finalized)状态(K或J)。该动作将影响某些其他对象从f-reachable状态重新回到reachable状态(L, M, N)
5. 处于finalizable状态的对象不能同时是unreahable的，由第4点可知，将对象finalizable对象标记为finalized时会由某个线程执行该对象的finalize方法，致使其变成reachable。这也是图中只有八个状态点的原因
6. 程序员手动调用finalize方法并不会影响到上述内部标记的变化，因此JVM只会至多调用finalize一次，即使该对象“复活”也是如此。程序员手动调用多少次不影响JVM的行为。
7. 若JVM检测到finalized状态的对象变成unreachable，回收其内存(I)
8. 若对象并未覆盖finalize方法，JVM会进行优化，直接回收对象（O）
9. 注：System.runFinalizersOnExit()等方法可以使对象即使处于reachable状态，JVM仍对其执行finalize方法。