【详解】GC如何判断一个对象是否需要被回收？引用计数法，可达性分析算法

【详解】GC如何判断一个对象是否需要被回收？引用计数法，可达性分析算法

        在堆中存放着Java世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前，第一件事就是确定哪些对象还存活着，哪些对象已经死去。

        JVM垃圾回收机制中如何判断一个对象是否需要被回收呢？

        JVM中给出了2种方法：引用计数法，可达性分析算法

（1）引用计数法

        它是这样描述的：在一个对象中添加一个引用计数器，每当有一个地方引用它得时候，计数器的值就加一；当引用失效时，计数器的值就减一；任何时刻计数器的为零的对象就是不可能再引用的。此时这样的对象就是需要被回收的对象。

        客观的说，引用计数法虽然占用了一些额外的空间进行计数，但是它得原理简单，判断效率也很高，在大多数情况下它都是一个不错的方法。但是在Java领域，至少主流的Java虚拟机里面没有选用引用计数法来管理内存。主要是因为有很多例外要考虑，必须要配合大量的处理才能保证正确的工作，比如单纯的引用计数就很难解决对象之间的互相循环引用的问题。比如A.instance = B以及B.instance = A，除此之外，这两个对象再无其他引用，实际上这两个对象不可能再被访问，但是引用他们互相引用着对方，导致他们的引用计数都不为零，使用引用计数法也无法回收他们。

（2）可达性分析算法

        当前主流的编程语言的内存管理系统，都是通过可达性分析算法来判断对象是否存活。基本思想：通过一系列成为“GC Roots”的根对象作为起始点，根据引用关系向下搜素，搜索过程所走过的路径称为引用链，如果某个对象到GC Roots没有任何引用链的话，就是从GC Roots到这个对象不可达，说明对象是不可能再被引用的。

        如图所示，object5,6,7虽然有关联，但是他们到GC Root是不可达的，因此他们判定为可回收的对象。

         在Java技术体系里，固定可作为GC Roots的对象有以下几种：

• 在虚拟机栈（栈帧中的本地变量表）中引用的对象，比如各个线程被调用的方法堆中使用到的参数，局部变量，临时变量等。
• 在方法区中类静态属性引用的对象，Java类的引用类型的静态变量。
• 在方法区常量引用的对象，比如字符串常量里的引用。
• 在本地方法栈JNI（本地Native方法）引用的对象。
• 所有被同步锁持有的对象。

注意：

        即使在可达性分析算法中对象被判定为不可达的对象，也不是“非死不可的”，这时候他们暂时还处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记的过程：如果对象进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会是第一次标记，随后再进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。假如对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，那么虚拟机视为这两种情况对象都没有必要执行finalize()方法。

        如果这个对象被判定为确实有必要执行finalize()方法，那么该对象就会被放到一个名为F-Queue的队列之中，并在稍后由虚拟机自动建立的，低调度的优先级的Finalizer线程去执行他们的finalize()方法。这里所说的执行是虚拟机触发这个方法开始执行，但并不承诺一定会等待它运算结束。如果某个方法的finalize()方法执行缓慢，或者更加极端的发生了死循环，很可能导致F-Queue队列中的其他对象一直处于等待状态，甚至导致整个内存回收系统的崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后收集器会对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救了自己，只要重新与引用链上的任何一个对象建立关联即可，譬如把自己赋值为某个类变量或者对象的成员变量，那在第二次标记中它即将被移出即将回收的集合；如果对象没有逃脱，那么基本上要被回收了。任何一个对象的finalize()方法只会被系统调用一次。