java相互引用的對象都置為null后為什么引用計數仍不為0

本篇內容介紹了“java相互引用的對象都置為null后為什么引用計數仍不為0”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

引用計數算法(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，而可達性算法就能解決這個問題。

情況(一):引用計數算法

如果采用的是引用計數算法:

• 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無法回收這兩個對象，而可達性算法則可以正確回收。

“java相互引用的對象都置為null后為什么引用計數仍不為0”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！