java为什么不用引用计数算法判断对象是否存活(相互引用的对象都置为null后,为什么引用计数仍不为0)

原创
2019/08/19 15:46
阅读数 247

引用计数算法(reference-counting):给对象中添加一个引用计数器,每当有一个地方引用它时,计数器就加1;当引用失效时,计数器就减1;任何时刻计数器都为0的对象就是不可能再被使用的,对于计数器为0的对象意味着是垃圾对象,可以被GC回收。

可达性算法(GC Roots Tracing):从GC Roots作为起点开始搜索,那么整个连通图中的对象便都是活对象,对于GC Roots无法到达的对象便成了垃圾回收的对象,随时可被GC回收。

下面通过一段代码来说明问题

/**
 * @description:
 * @version: 1.0
 * @author: xuanyong
 * @date:2019/8/19
 */
public class GcObject {

    public Object instance = null;

    private static final int _1MB = 1024*1024;

    /**
     * 这个成员属性的唯一意义就是占点内存,以便能在GC日志中看清楚是否被回收过
     */
    private byte[] bigSize = new byte[2*_1MB];

    public static void testGC(){
        GcObject obj1 = new GcObject(); //Step 1
        GcObject obj2 = new GcObject(); //Step 2
        obj1.instance = obj2; //Step3
        obj2.instance = obj1; //Step4

        obj1 = null; //Step5
        obj2 = null; //Step6

        // 假设这行发生GC,那么objA和objB是否能被回收?
        System.gc();
    }


    public static void main(String[] args) {
        testGC();
    }
}

通过IDEA查看上述代码运行GC日志(自行百度idea如何查看GC日志)

[GC (System.gc()) [PSYoungGen: 9340K->824K(76288K)] 9340K->832K(251392K), 0.0150995 secs] [Times: user=0.00 sys=0.00, real=0.02 secs] 
[Full GC (System.gc()) [PSYoungGen: 824K->0K(76288K)] [ParOldGen: 8K->639K(175104K)] 832K->639K(251392K), [Metaspace: 3281K->3281K(1056768K)], 0.0040434 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 PSYoungGen      total 76288K, used 655K [0x000000076b200000, 0x0000000770700000, 0x00000007c0000000)
  eden space 65536K, 1% used [0x000000076b200000,0x000000076b2a3ee8,0x000000076f200000)
  from space 10752K, 0% used [0x000000076f200000,0x000000076f200000,0x000000076fc80000)
  to   space 10752K, 0% used [0x000000076fc80000,0x000000076fc80000,0x0000000770700000)
 ParOldGen       total 175104K, used 639K [0x00000006c1600000, 0x00000006cc100000, 0x000000076b200000)
  object space 175104K, 0% used [0x00000006c1600000,0x00000006c169fde8,0x00000006cc100000)
 Metaspace       used 3288K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 359K, capacity 388K, committed 512K, reserved 1048576K

Process finished with exit code 0

为什么上述代码引用计数objA和objB不为0,而可达性算法就能解决这个问题。

情况(一):引用计数算法

如果采用的是引用计数算法:

再回到前面代码GcObject 的testGC方法共分为6个步骤:

  • Step1:GcObject实例1的引用计数加1,实例1的引用计数=1;
  • Step2:GcObject实例2的引用计数加1,实例2的引用计数=1;
  • Step3:GcObject实例2的引用计数再加1,实例2的引用计数=2;
  • Step4:GcObject实例1的引用计数再加1,实例1的引用计数=2;执行到Step4

执行到Step4,则GcObject实例1和实例2的引用计数都等于2。

接下来继续结果图:

  • Step5:栈帧中obj1不再指向java堆,GcObject实例1的引用计数减1,结果为1;
  • Step6:栈帧中obj2不再指向java堆,GcObject实例2的引用计数减1,结果为1;

到此,发现GcObjcect实例1和实例2的计数引用都不为0,那么如果采用引用计数算法的话,那么两个实例所占的内存将得不到释放,这便产生内存泄漏。

情况(二):可达性算法

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

那么可以作为GC Roots的对象(见下图):

  • 虚拟机栈的栈帧的局部变量表所引用的对象;
  • 本地方法栈的JNI所引用的对象;
  • 方法区的静态变量和常量所引用的对象;

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

从上图,reference1、reference2、reference3都是GC Roots,可以看出:

  • reference1-> 对象实例1;
  • reference2-> 对象实例2;
  • reference3-> 对象实例4;
  • reference3-> 对象实例4 -> 对象实例6;

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

到这里,相信大家应该能彻底明白引用计数算法和可达性算法的区别吧

再回过头来看看最前面的实例,GcObject实例1和实例2虽然从引用计数虽然都不为0,但从可达性算法来看,都是GC Roots不可达的对象。

总之,对于对象之间循环引用的情况,引用计数算法,则GC无法回收这两个对象,而可达性算法则可以正确回收。

 

见Gityuan。

 

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部