垃圾回收相关算法

这里介绍的垃圾回收相关算法，主要解决的问题：

判断哪些内存是垃圾（需要回收的）？

常用的两种算法：

• 引用计数
• 可达性分析（GC Root）

首先介绍算法前，得定义：

如何判断一个对象的死亡？

我们一般这样定义：当一个对象不再被任何存活的对象继续引用的时候，这个对象就死亡了。

引用计数

引用计数算法，是给每一个对象添加一个计数器，当有对象引用它的时候，计数器+1，当有对象取消对它的引用时，计数就会-1。

当计数器的值为 0 时，即说明没有对象引用它，也就是这个对象死亡了。

这种算法很简单，但是有个重大缺陷，那就是无法解决循环引用的问题。

什么是循环引用问题呢？

比如对象A 引用 对象B，对象B 引用 对象A，那么 对象A 和 对象B 的计数器都为1。但是如果后续的运行环境再也用不到对象A 和 对象B，那么就造成了内存泄漏。

上图就是循环引用的例子。对象引用 Obj1 和 Obj2 在栈中，然后分别指向在堆中的具体实例。然后两个相互实例中的成员互相引用。那么对于堆中的对象而言，就有2个引用。一个是来自Obj1，一个来自堆对象的另一方。

如果，现在将 Obj1 指向 nu l l，那么就如下图：

这个时候，引用已经不可用了，但是堆中的对象仍然相互引用，他们的计数器不为0，所以无法死亡。

但是，Java 没有使用这种算法，而是使用了我们后面说的可达性算法，所以接下来的演示，GC 会将这种情况的内存给其清理。

package GC;

public class ReferenceCountGC {
    public Object instance = null;

    private static final int _1MB = 1024 * 1024;
    // 每个对象中包含2M的成员，方便观察
    private byte[] bigSize = new byte[2 * _1MB];
    public static void main(String[] args) {
        ReferenceCountGC objA = new ReferenceCountGC();
        ReferenceCountGC objB = new ReferenceCountGC();
        objA.instance = objB.instance;
        objB.instance = objA.instance;

        //取消对对象的引用
        objA = null;
        objB = null;
      // 是否进行垃圾回收
        System.gc();
    }
}

这段代码实现的就是上面图片所描述的情况。

首先，我们将 System.gc() 注释掉，也就是我们在默认情况下，不去触发垃圾回收。并在运行的时候，添加参数 -XX:+PrintGCDetails。我们观察输出结果

可以看到，这个时候，占用的空间为8M左右。

如果我们取消注释，也就是主动去调用垃圾回收器，那么运行结果为：

占用空间为2M左右。

可以看出来，Java 的垃圾回收，并非采用我们上面介绍的引用计数方式。

可达性分析

可达性算法，还有一系列的别名：根搜索算法，追踪性垃圾收集，GC Root。

之后，看到原理，其实这些别名都是描述原理的。

首先，我们选取一些对象，这些对象是存活的，也被称为 GC Roots，然后根据这些对象的引用关系，凡是直接或者间接跟 GC Roots 相关联的对象，都是存活的。就像图中的连通性判断一样。

这个算法的想法不难。难的是，如何确定 GC Roots。

我们考虑，我们什么时候需要用到对象？（我们需要对象的时候，肯定需要这个对象是存活的）

• 栈中保存着，我们当前或者之后需要运行的方法及相关参数，所以，栈上所引用的堆中对象肯定是存活的。
• 类中的一些属性，比如，静态属性，因为它不依赖于具体的类
• 一些常用的对象，以免清理后，又要重复加载，比如常用的异常对象，基本数据类型对应的 Class 对象。

除此之外，还有很多零零碎碎的。

在堆结构周围的一些结构，其中引用的对象可以作为GC Roots

具体 GC Roots 可以概括为：

• 虚拟机栈上（确切的说，是栈帧上的本地变量表）所引用的对象

• 本地方法栈引用的对象

• 方法区中的静态属性，常量引用

• Java 虚拟机的内部引用，常用数据类型的 Class 对象，常驻的异常对象，系统类加载器

• 所有被同步锁持有的对象

除此之外，还有一些临时的 GC Roots 可以加入进来。这里涉及到新生代老年代。

比如老年代中的对象一般都存活时间比较久，也就是大概率是活着的对象，也可临时作为 GC Roots。

可达性算法的一些细节

前面说了可达性算法，我们根据 GC Roots 来进行标记对象的死活。

但是，被判定为不可达的对象，并不立刻死亡。它仍然有次机会进行自救。

这个自救的机会，是需要重写 finalize（）进行自救。

也就是可达性算法的逻辑大致是这样的：

• 第一次进行标记，凡是不可达 GC Roots 的对象，都暂时判定为死亡，只是暂时
• 检查暂时被判定为死亡对象，检查是否有重写 finalize（）方法，如果有，则触发，对象可以在里面完成自救。

如果没有自救成功 或者 没有重写 finalize（）方法，则宣告这个对象的死亡。

除此之外，这个对象中的 finalize（）方法，只能被调用一次，一生只有一次自救机会。

这个方法，官方并不推荐，所以不必细究。

接下来，演示下上面的两次标记过程以及自救过程。

（个人认为，《深入理解 Java 虚拟机》中的此章节代码，略有点不够完善，故略微改动）

package GC;

import javax.swing.tree.VariableHeightLayoutCache;

public class FinalizeEscapeGC {
    public static FinalizeEscapeGC SAVE_HOOK = null;

    private byte[] bigSize = new byte[5*1024*1024];

    public void isAlive(){
        System.out.println("Yes, i am alive");
    }

    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("Finalize method executed");
        FinalizeEscapeGC.SAVE_HOOK = this;
    }

    public static void main(String[] args) throws InterruptedException {
        SAVE_HOOK = new FinalizeEscapeGC();
        SAVE_HOOK = null;
        System.gc();
        Thread.sleep(500);
        if(SAVE_HOOK != null){
            SAVE_HOOK.isAlive();
            System.gc();
        }else {
            System.out.println("Dead");
            System.gc();
        }
    }
}

在这个程序中，我们给这个类，添加名为 bigSize 的属性，其占用 4M 大小的空间。

大致分析下代码逻辑：

• 创建了一个对象，其中有成员占用 4M 的空间
• 取消对这个对象的引用
• 调用垃圾回收（第一次标记）
• 调用 finalize 方法进行自救
• 之后再次调用垃圾回收（第二次标记）

所以演示的时候，分为两种情况：

• FinalizeEscapeGC.SAVE_HOOK = this; 未注释，完成自救

运行时，参数仍然设置为 +XX:PrintGCDetails，可以看到输出结果：

第一次调用垃圾回收，仍然占用 5M，说明此时即便失去引用，但是仍然未被清理。

在 finalize（）中完成自救后，第二次调用垃圾回收的时候，仍然占用 5M 的内存大小。说明自救成功。

• FinalizeEscapeGC.SAVE_HOOK = this; 注释，无法完成自救

第一次垃圾回收，占用 5M，保留了对象。无法完成自救，然后第二次被清理掉。

所以我发现以下表述也许更为确切：

• 当对象重写了 finalize（）方法的时候，第一次垃圾回收的时候，如果为不可达对象，对其进行暂缓，并不清理。
• 当对象没有重写 finalize（）方法的时候，且为不可达对象的时候，直接判定死亡。