Java虛擬機器15：再談四種引用狀態

JVM的四種引用狀態

在Java虛擬機器5：Java垃圾回收（GC）機制詳解一文中，有簡單提到過JVM的四種引用狀態，當時只是簡單學習，知道有這麼一個概念，對四種引用狀態理解不深。這兩天重看虛擬機器這部分的時候，寫了很多例子詳細研究了一下JVM的幾種引用，對於JVM的引用理解加深了不少，因此總結寫一篇文章總結並分享下。

首先，還是先從JVM四種引用狀態開始，這部分摘抄自周志明老師的《深入理解Java虛擬機器：JVM高階特性與最佳實踐》一書。

在JDK1.2之前，Java中的引用的定義很傳統：如果reference型別的資料中儲存的數值代表的是另外一塊記憶體的起始地址，就稱這塊記憶體代表著一個引用。這種定義很純粹，但是太過狹隘，一個物件在這種頂一下只有被引用或者沒有被引用兩種狀態，對於如何描述一些"食之無味，棄之可惜"的物件就顯得無能為力。我們希望能描述這樣一類物件：當記憶體空間還足夠時，則能保留在記憶體之中；如果記憶體空間在進行垃圾收集後還是非常緊張，則可以拋棄這些物件（注意和前面一段藍字的對比學習）。很多系統的快取功能都符合這樣的引用場景。

在JDK1.2之後，Java對引用的概念進行了擴充，將引用分為強引用（Strong Reference）、軟引用（Soft Reference）、弱引用（Weak Reference）、虛引用（Phantom Reference）4種，這4中引用強度一次減弱。

• 強引用就是指在程式程式碼之中普遍存在的，類似"Object obj = new Object()"這類的引用，只要強引用還存在，垃圾收集器永遠不會回收掉被引用的物件
• 軟引用是用來描述一些還有用但並非必需的物件，對於軟引用關聯著的物件，在系統將要發生記憶體溢位異常之前，將會把這些物件列進回收範圍進行第二次回收。如果這次回收還沒有足夠的記憶體，才會丟擲記憶體溢位異常。在JDK1.2之後，提供了SoftReference類來實現軟引用
• 弱引用也是用來描述非必需物件的，但是它的強度比軟引用更弱一些，被弱引用關聯的物件，只能生存到下一次垃圾收集發生之前。當垃圾收集器工作時，無論當前記憶體是否足夠，都會回收掉只被弱引用關聯的物件。在JDK1.2之後，提供了WeakReference類來實現弱引用
• 虛引用也成為幽靈引用或者幻影引用，它是最弱的一中引用關係。一個物件是否有虛引用的存在，完全不會對其生存時間構成影響，也無法通過虛引用來取得一個物件例項。為一個物件設定虛引用關聯的唯一目的就是能在這個物件被收集器回收時收到一個系統通知。在JDK1.2之後，提供給了PhantomReference類來實現虛引用

 

寫於程式碼開始前

在通過程式碼研究幾種引用狀態之前，先定義一些引數，後面所有部分的程式碼示例都使用這些引數。

首先是JVM的引數，這裡我使用的是：

-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+UseParNewGC -verbose:gc -XX:+PrintGCDetails

這意味著：

• 堆大小固定為20M
• 新生代大小為10M，SurvivorRatio設定為8，則Eden區大小=8M，每個Survivor區大小=1M，每次有9M的新生代記憶體空間可用來new物件
• 新生代使用使用ParNew收集器，Server模式下預設是Parallel收集器，不過這個收集器的GC日誌我看著沒有ParNew收集器的GC日誌舒服，因此就改成ParNew收集器了
• 當發生GC的時候列印GC的簡單資訊，當程式執行結束列印GC詳情

其次，再定義一個常量類"_1MB"：

/**
 * 1M
 */
private static final int _1MB = 1024 * 1024;

程式碼示例使用byte陣列，每個byte為1個位元組，因此定義一個"_1MB"的常量就可以方便得到1M、2M、3M...的記憶體空間了。

 

強引用的研究

關於強引用的研究，研究的重點在於驗證"當一個物件到GC Roots沒有任何引用鏈相連，則證明此物件是不可用的（要被回收）"這句話的正確性。虛擬機器引數上面列了，首先寫一個空方法：

/**
 * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7082471.html
 */
@Test
public void testStrongReference0() {

}

程式執行結果為：

Heap
 par new generation   total 9216K, used 3699K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
  eden space 8192K,  45% used [0x00000000f9a00000, 0x00000000f9d9cdc0, 0x00000000fa200000)
  from space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
  to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
 tenured generation   total 10240K, used 0K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,   0% used [0x00000000fa400000, 0x00000000fa400000, 0x00000000fa400200, 0x00000000fae00000)
 compacting perm gen  total 21248K, used 4367K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
   the space 21248K,  20% used [0x00000000fae00000, 0x00000000fb243d88, 0x00000000fb243e00, 0x00000000fc2c0000)
No shared spaces configured.

這意味著新生代中本身就有3699K的記憶體空間。很好理解，因為虛擬機器啟動的時候就會載入一部分資料到記憶體中，這部分資料的大小為3699K。

下一步我們放一個4M的byte陣列進去（4M是因為找一個相對大點的數字，結果會比較明顯），4M=4096K，加上原來的3966K等於8062K。對這8062K記憶體空間觸發一次GC：

/**
 * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7082471.html
 */
@Test
public void testStrongReference0() {
    System.out.println("**********強引用測試（放一個4M的陣列，觸發GC）**********");
        
    byte[] bytes = new byte[4 * _1MB];
        
    // 手動觸發GC
    System.gc();
}

執行結果為：

**********強引用測試（放一個4M的陣列，觸發GC）**********
[Full GC[Tenured: 0K->5161K(10240K), 0.0085630 secs] 7958K->5161K(19456K), [Perm : 4354K->4354K(21248K)], 0.0086002 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
Heap
 par new generation   total 9216K, used 284K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
  eden space 8192K,   3% used [0x00000000f9a00000, 0x00000000f9a47300, 0x00000000fa200000)
  from space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
  to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
 tenured generation   total 10240K, used 5161K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  50% used [0x00000000fa400000, 0x00000000fa90a548, 0x00000000fa90a600, 0x00000000fae00000)
 compacting perm gen  total 21248K, used 4367K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
   the space 21248K,  20% used [0x00000000fae00000, 0x00000000fb243dc0, 0x00000000fb243e00, 0x00000000fc2c0000)
No shared spaces configured.

總結一下這次GC的結果（由於這篇不是研究記憶體分配的文章，因此我們只關注結果，至於過程到底為什麼就不細究了）：

• 新生代中只留下了284K大小的物件
• 7958K大小的物件被移到了老年代中
• 7958K大小的物件被進行了一次回收，剩餘5161K大小的物件

總結起來就是4M的byte陣列並沒有被回收（因為總共有5161K的物件，虛擬機器啟動的時候也才載入了3699K不到5161K，那4M的byte陣列肯定是在的），原因是有bytes引用指向4M的byte陣列。既然如此，我們把bytes置空看看結果如何：

/**
 * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7082471.html
 */
@Test
public void testStrongReference0() {
    System.out.println("**********強引用測試（放一個4M的陣列，bytes置空，觸發GC）**********");
        
    byte[] bytes = new byte[4 * _1MB];
        
    bytes = null;
        
    // 手動觸發GC
    System.gc();
}

執行結果為：

**********強引用測試（放一個4M的陣列，bytes置空，觸發GC）**********
[Full GC[Tenured: 0K->1064K(10240K), 0.0096213 secs] 7958K->1064K(19456K), [Perm : 4354K->4354K(21248K)], 0.0096644 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
Heap
 par new generation   total 9216K, used 284K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
  eden space 8192K,   3% used [0x00000000f9a00000, 0x00000000f9a47300, 0x00000000fa200000)
  from space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
  to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
 tenured generation   total 10240K, used 1064K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  10% used [0x00000000fa400000, 0x00000000fa50a368, 0x00000000fa50a400, 0x00000000fae00000)
 compacting perm gen  total 21248K, used 4367K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
   the space 21248K,  20% used [0x00000000fae00000, 0x00000000fb243dc0, 0x00000000fb243e00, 0x00000000fc2c0000)
No shared spaces configured.

從GC詳情我們可以看到：

• 老年代只使用了1064K大小的記憶體
• 新生代只使用了284K大小的記憶體

很顯然4M的byte陣列被回收。

由這個例子我們回顧可以作為GC Roots的物件：

• 虛擬機器棧（棧幀中的本地變數表）中引用的物件，比如在方法中定義"Object obj = new Object();"
• 方法區中類靜態屬性引用的物件，比如在類中定義"private static Object lock = new Object();"，將Object物件作為一個鎖，所有類共享
• 方法區中常量引用的物件，比如在介面中定義"public static final char c = 'a';"，字元'a'是一個常量
• 本地方法棧中JNI（即一般說的Native方法）引用的物件，這個不好找例子

這次的回收正是因為第一條。本身有bytes（在虛擬機器棧中）指向4M的byte陣列，由於將bytes置空。因此4M的byte陣列此時沒有任何一個可以作為GC Roots物件的引用指向它，即4M的byte陣列被虛擬機器標記為可回收的垃圾，在GC時被回收。

稍微擴充套件一下，這裡上面程式碼的做法是手動將bytes置空，其實方法呼叫結束也是一樣的，棧幀消失，棧幀消失意味著bytes消失，那麼4M的byte陣列同樣沒有任何一個可以作為GC Roots物件的引用指向它，因此方法呼叫結束之後，4M的byte陣列同樣會被虛擬機器標記為可回收的垃圾，在GC時被回收。

 

軟引用的研究

軟引用之前說過了，JDK提供了SoftReference類共開發者使用，那我們就利用SoftReference研究一下軟引用，測試程式碼為：

/**
 * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7082471.html
 */
@Test
public void testSoftReference0() {
    System.out.println("**********軟引用測試**********");
        
    byte[] bytes = new byte[4 * _1MB];
    SoftReference<byte[]> sr = new SoftReference<byte[]>(bytes);
    System.out.println("GC前：" + sr.get());
        
    bytes = null;
        
    System.gc();
    System.out.println("GC後：" + sr.get());
}

同樣的new一個4M的byte陣列，通過SoftReference構造方法放到SoftReference中。

這段程式碼最值得注意的是第9行"bytes=null"這一句，如果不將bytes置空，那麼4M的byte陣列還與強引用關聯著，記憶體不夠虛擬機器將丟擲異常而不會嘗試回收它；將bytes置空則不一樣，4M的byte陣列失去了強引用，但是它又在SoftReference中，這意味著這個4M的byte陣列目前僅僅與軟引用關聯。

執行一下程式，結果為：

**********軟引用測試**********
GC前：[B@76404629
[Full GC[Tenured: 0K->5161K(10240K), 0.0094088 secs] 7953K->5161K(19456K), [Perm : 4354K->4354K(21248K)], 0.0094428 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
GC後：[B@76404629
Heap
 par new generation   total 9216K, used 284K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
  eden space 8192K,   3% used [0x00000000f9a00000, 0x00000000f9a47330, 0x00000000fa200000)
  from space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
  to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
 tenured generation   total 10240K, used 5161K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  50% used [0x00000000fa400000, 0x00000000fa90a778, 0x00000000fa90a800, 0x00000000fae00000)
 compacting perm gen  total 21248K, used 4367K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
   the space 21248K,  20% used [0x00000000fae00000, 0x00000000fb243f10, 0x00000000fb244000, 0x00000000fc2c0000)
No shared spaces configured.

看到GC前後，bytes都是"[B@76404629"，很顯然4M的byte陣列並沒有被回收。從記憶體空間來看，老年代中使用了5161K，和之前強引用測試是一樣的，證明了這一點。

那我們怎麼能看到弱引用的回收呢？既然弱引用是發生在記憶體不夠之前，那隻需要不斷例項化byte陣列，然後將之與軟引用關聯即可，程式碼為：

/**
 * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7082471.html
 */
@Test
public void testSoftReference1() {
    System.out.println("**********軟引用測試**********");
            
    SoftReference<byte[]> sr0 = new SoftReference<byte[]>(new byte[4 * _1MB]);
    SoftReference<byte[]> sr1 = new SoftReference<byte[]>(new byte[4 * _1MB]);
    SoftReference<byte[]> sr2 = new SoftReference<byte[]>(new byte[4 * _1MB]);
    SoftReference<byte[]> sr3 = new SoftReference<byte[]>(new byte[4 * _1MB]);
    SoftReference<byte[]> sr4 = new SoftReference<byte[]>(new byte[4 * _1MB]);
    SoftReference<byte[]> sr5 = new SoftReference<byte[]>(new byte[4 * _1MB]);
            
    System.out.println(sr0.get());
    System.out.println(sr1.get());
    System.out.println(sr2.get());
    System.out.println(sr3.get());
    System.out.println(sr4.get());
    System.out.println(sr5.get());
}

執行結果為：

**********軟引用測試**********
[GC[ParNew: 7958K->1024K(9216K), 0.0041103 secs] 7958K->5187K(19456K), 0.0041577 secs] [Times: user=0.05 sys=0.00, real=0.00 secs] 
[GC[ParNew: 5203K->331K(9216K), 0.0036532 secs] 9366K->9481K(19456K), 0.0036694 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC[ParNew: 4427K->4427K(9216K), 0.0000249 secs][Tenured: 9149K->9149K(10240K), 0.0054937 secs] 13577K->13246K(19456K), [Perm : 4353K->4353K(21248K)], 0.0055600 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
[Full GC[Tenured: 9149K->783K(10240K), 0.0071252 secs] 13246K->783K(19456K), [Perm : 4353K->4352K(21248K)], 0.0071560 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
[GC[ParNew: 4096K->41K(9216K), 0.0010362 secs] 4879K->4921K(19456K), 0.0010745 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC[ParNew: 4137K->10K(9216K), 0.0009216 secs] 9017K->8986K(19456K), 0.0009366 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
null
null
null
[B@4783165b
[B@6f30d50a
[B@6ef2bc8d
Heap
 par new generation   total 9216K, used 4307K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
  eden space 8192K,  52% used [0x00000000f9a00000, 0x00000000f9e32560, 0x00000000fa200000)
  from space 1024K,   1% used [0x00000000fa200000, 0x00000000fa202978, 0x00000000fa300000)
  to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
 tenured generation   total 10240K, used 8975K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  87% used [0x00000000fa400000, 0x00000000facc3f40, 0x00000000facc4000, 0x00000000fae00000)
 compacting perm gen  total 21248K, used 4366K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
   the space 21248K,  20% used [0x00000000fae00000, 0x00000000fb2439e0, 0x00000000fb243a00, 0x00000000fc2c0000)
No shared spaces configured.

從第8行~第13行的結果來看，前三個4M的byte陣列被回收了，後三個4M的byte陣列還在，這就證明了"被軟引用關聯的物件會在記憶體不夠時被回收"。

這段程式碼我們可以做一個對比思考：

• 如果4M的byte陣列沒有被軟引用關聯而是被強引用關聯，且不釋放強引用，那麼new到第4個4M的byte陣列時就會報錯，因為老年代總共只有10M，前兩個4M的byte陣列可以進入老年代，第3個4M的byte陣列new出來的時候放入新生代，但是當第四個4M的byte陣列new出來的時候，第3個4M的byte陣列卻沒法進入老年代（因為3個4M=12M，大於老年代的10M），虛擬機器丟擲OutOfMemoryError
• 如果4M的byte陣列被軟引用關聯且強引用已經釋放，那麼可以無限寫"SoftReference<byte[]> sr = new SoftReference<byte[]>(new byte[4 * _1MB]);"這句程式碼，因為記憶體不夠了就回收4M的byte陣列，永遠沒有記憶體溢位的可能

所以，很多時候對一些非必需的物件，我們可以將直接將其與軟引用關聯，這樣記憶體不夠時會先回收軟引用關聯的物件而不會丟擲OutOfMemoryError，畢竟丟擲OutOfMemoryError意味著整個應用將停止執行。

 

弱引用的研究

JDK給我們提供的了WeakReference用以將一個物件關聯到弱引用，弱引用的測試比較簡單，程式碼為：

/**
 * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7082471.html
 */
@Test
public void testWeakReference() {
    System.out.println("**********弱引用測試**********");
        
    WeakReference<byte[]> wr = new WeakReference<byte[]>(new byte[4 * _1MB]);
    System.out.println("GC前：" + wr.get());
        
    System.gc();
    System.out.println("GC後：" + wr.get());
}

我這裡不定義一個強引用直接關聯4M的byte陣列（避免忘了將物件與強引用的關聯取消），這也是使用SoftReference、WeakReference時我個人比較推薦的做法。程式執行的結果為：

**********弱引用測試**********
GC前：[B@21dd63a8
[Full GC[Tenured: 0K->1065K(10240K), 0.0080353 secs] 7958K->1065K(19456K), [Perm : 4353K->4353K(21248K)], 0.0080894 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
GC後：null
Heap
 par new generation   total 9216K, used 284K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
  eden space 8192K,   3% used [0x00000000f9a00000, 0x00000000f9a47318, 0x00000000fa200000)
  from space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
  to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
 tenured generation   total 10240K, used 1065K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  10% used [0x00000000fa400000, 0x00000000fa50a6e8, 0x00000000fa50a800, 0x00000000fae00000)
 compacting perm gen  total 21248K, used 4367K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
   the space 21248K,  20% used [0x00000000fae00000, 0x00000000fb243dc8, 0x00000000fb243e00, 0x00000000fc2c0000)
No shared spaces configured.

看到GC後bytes為null了，且新生代、老年代中也沒見到有4M以上的大物件，從兩個角度都證明了，GC之後4M的byte陣列被回收了。

 

Reference與ReferenceQueue

前面用程式碼驗證了強引用、軟應用、弱引用三種引用狀態，虛引用就不演示了，記住虛引用是用於跟蹤物件的回收狀態就夠了。

下面再講一個知識點ReferenceQueue，ReferenceQueue的作用分點講解下：

1. SoftReference、WeakReference、PhantomReference，在構造的時候可以通過建構函式傳入一個ReferenceQueue，但是隻有PhantomReference，ReferenceQueue是必須的
2. 以SoftReference為例，一個型別為SoftReference的sr關聯了一個4M的byte陣列，那麼當記憶體不夠的時候，回收此4M的byte陣列，sr.get()為null，表示sr不再關聯此4M的byte陣列
3. 當sr對應的4M的byte陣列被回收之後，sr本身被加入ReferenceQueue中，表示此軟引用關聯的物件被回收
4. ReferenceQueue本身是一個Queue，可通過poll()方法不斷拿到佇列的頭元素，如果是null表示沒有被回收的軟引用關聯的物件，如果不是null表示有軟引用關聯的物件被回收
5. SoftReference是這樣的，WeakReference與PhantomReference同理

講完理論，用程式碼驗證一下，還是使用軟引用，不過為了顯示更清楚把GC顯示相關引數（-verbose:gc  -XX:+PrintGCDetails）去掉，程式碼為：

/**
 * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7082471.html
 */
@Test
public void testReferenceQueue() {
    System.out.println("**********引用佇列測試**********\n");
        
    ReferenceQueue<byte[]> referenceQueue = new ReferenceQueue<byte[]>();
        
    SoftReference<byte[]> sr0 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);
    SoftReference<byte[]> sr1 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);
    SoftReference<byte[]> sr2 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);
    SoftReference<byte[]> sr3 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);
    SoftReference<byte[]> sr4 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);
    SoftReference<byte[]> sr5 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);
        
    System.out.println("**********軟引用關聯的物件展示**********");
    System.out.println(sr0 + "---" + sr0.get());
    System.out.println(sr1 + "---" + sr1.get());
    System.out.println(sr2 + "---" + sr2.get());
    System.out.println(sr3 + "---" + sr3.get());
    System.out.println(sr4 + "---" + sr4.get());
    System.out.println(sr5 + "---" + sr5.get());
        
    System.out.println("**********引用佇列中的SoftReference展示**********");
    System.out.println(referenceQueue.poll());
    System.out.println(referenceQueue.poll());
    System.out.println(referenceQueue.poll());
    System.out.println(referenceQueue.poll());
    System.out.println(referenceQueue.poll());
    System.out.println(referenceQueue.poll());
}

執行結果為：

**********引用佇列測試**********

**********軟引用關聯的物件展示**********
java.lang.ref.SoftReference@50ed0a5---null
java.lang.ref.SoftReference@fa4033b---null
java.lang.ref.SoftReference@58d01e82---null
java.lang.ref.SoftReference@4783165b---[B@6f30d50a
java.lang.ref.SoftReference@6ef2bc8d---[B@23905e3
java.lang.ref.SoftReference@6db17b38---[B@1f10d1cb
**********引用佇列中的SoftReference展示**********
java.lang.ref.SoftReference@50ed0a5
java.lang.ref.SoftReference@fa4033b
java.lang.ref.SoftReference@58d01e82
null
null
null

看到由於記憶體不夠，回收了前三個軟引用，且回收的三個軟引用記憶體地址都能對得上，這證明了上面的說法。

 

虛引用的研究

本來不準備寫虛引用的，因為比較簡單，虛引用唯一的目的只是跟蹤物件的回收。不過後面有網友朋友提出了問題，我自己看了一下，虛引用確實有一個容易混淆的地方，因此文章更新，最後一部分加上虛引用。

測試程式碼為：

/**
 * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7082471.html
 */
@Test
public void testPhantomReference() {
    System.out.println("**********虛引用測試**********");
        
    ReferenceQueue<byte[]> referenceQueue = new ReferenceQueue<byte[]>();
        
    byte[] bytes = new byte[4 * _1MB];
    PhantomReference<byte[]> pr = new PhantomReference<byte[]>(bytes, referenceQueue);
        
    bytes = null;
        
    System.gc();
        
    System.out.println(referenceQueue.poll());
    JdkUtil.sleep(100);
    System.out.println(referenceQueue.poll());
}

第13行bytes置空，此時4M的byte陣列只關聯了虛引用。這裡的重點程式碼是第17行~第19行三行，程式碼執行結果為：

**********虛引用測試**********
[Full GC[Tenured: 0K->5163K(10240K), 0.0108148 secs] 7795K->5163K(19456K), [Perm : 4355K->4355K(21248K)], 0.0108713 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
null
java.lang.ref.PhantomReference@6f30d50a
Heap
 par new generation   total 9216K, used 365K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
  eden space 8192K,   4% used [0x00000000f9a00000, 0x00000000f9a5b768, 0x00000000fa200000)
  from space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
  to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
 tenured generation   total 10240K, used 5163K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  50% used [0x00000000fa400000, 0x00000000fa90acf8, 0x00000000fa90ae00, 0x00000000fae00000)
 compacting perm gen  total 21248K, used 4371K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
   the space 21248K,  20% used [0x00000000fae00000, 0x00000000fb244e98, 0x00000000fb245000, 0x00000000fc2c0000)
No shared spaces configured.

看到第一次從佇列中取沒有取到虛引用，休眠100ms之後卻從佇列中取到了虛引用，且GC輸出也看得出來，新生代和老年代中沒有大物件了，說明4M的byte陣列確實被回收。

講這個問題，首先看一下JDK API對於PhantomReference的描述：

注意紅字，物件是虛可達到物件，物件在那時或者在以後的某一時間，它會將該引用加入佇列，那麼什麼時候加入該引用佇列？答案是被虛引用關聯的物件真正被回收的時候。

之前我們說了，虛引用唯一的作用是用於跟蹤物件的垃圾回收的，System.gc()方法呼叫的時候，4M的byte陣列並沒有被馬上回收，System.gc()方法只是發出一個通知：建議觸發GC。

當4M的byte陣列真正被回收的時候，虛引用加入引用佇列。因此一開始獲取佇列頭的時候佇列頭為null，休眠100ms之後確保物件被回收，佇列頭中有虛引用。