• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

垃圾回收相关算法

开发技术 开发技术 2周前 (06-20) 14次浏览

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

判断哪些内存是垃圾(需要回收的)?

常用的两种算法

  • 引用计数
  • 可达性分析(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()方法的时候,且为不可达对象的时候,直接判定死亡。

喜欢 (0)