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沒有任何引用鏈相連，則證實此對象是不可用的（要被回收）"這句話的正確性。虛擬機參數上面列了，首先寫一個空方法：

 1 /**
 2  * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7082471.html
 3  */
 4 @Test
 5 public void testStrongReference0() {
 6 
 7 }

程序運行結果爲：

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

這意味着新生代中自己就有3699K的內存空間。很好理解，由於虛擬機啓動的時候就會加載一部分數據到內存中，這部分數據的大小爲3699K。

下一步咱們放一個4M的byte數組進去（4M是由於找一個相對大點的數字，結果會比較明顯），4M=4096K，加上原來的3966K等於8062K。對這8062K內存空間觸發一次GC：

 1 /**
 2  * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7082471.html
 3  */
 4 @Test
 5 public void testStrongReference0() {
 6     System.out.println("**********強引用測試（放一個4M的數組，觸發GC）**********");
 7         
 8     byte[] bytes = new byte[4 * _1MB];
 9         
10     // 手動觸發GC
11     System.gc();
12 }

運行結果爲：

 1 **********強引用測試（放一個4M的數組，觸發GC）**********
 2 [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] 
 3 Heap
 4  par new generation   total 9216K, used 284K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
 5   eden space 8192K,   3% used [0x00000000f9a00000, 0x00000000f9a47300, 0x00000000fa200000)
 6   from space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
 7   to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
 8  tenured generation   total 10240K, used 5161K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
 9    the space 10240K,  50% used [0x00000000fa400000, 0x00000000fa90a548, 0x00000000fa90a600, 0x00000000fae00000)
10  compacting perm gen  total 21248K, used 4367K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
11    the space 21248K,  20% used [0x00000000fae00000, 0x00000000fb243dc0, 0x00000000fb243e00, 0x00000000fc2c0000)
12 No shared spaces configured.

總結一下此次GC的結果（因爲這篇不是研究內存分配的文章，所以咱們只關注結果，至於過程到底爲何就不細究了）：

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

總結起來就是4M的byte數組並無被回收（由於總共有5161K的對象，虛擬機啓動的時候也才加載了3699K不到5161K，那4M的byte數組確定是在的），緣由是有bytes引用指向4M的byte數組。既然如此，咱們把bytes置空看看結果如何：

 1 /**
 2  * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7082471.html
 3  */
 4 @Test
 5 public void testStrongReference0() {
 6     System.out.println("**********強引用測試（放一個4M的數組，bytes置空，觸發GC）**********");
 7         
 8     byte[] bytes = new byte[4 * _1MB];
 9         
10     bytes = null;
11         
12     // 手動觸發GC
13     System.gc();
14 }

運行結果爲：

 1 **********強引用測試（放一個4M的數組，bytes置空，觸發GC）**********
 2 [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] 
 3 Heap
 4  par new generation   total 9216K, used 284K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
 5   eden space 8192K,   3% used [0x00000000f9a00000, 0x00000000f9a47300, 0x00000000fa200000)
 6   from space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
 7   to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
 8  tenured generation   total 10240K, used 1064K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
 9    the space 10240K,  10% used [0x00000000fa400000, 0x00000000fa50a368, 0x00000000fa50a400, 0x00000000fae00000)
10  compacting perm gen  total 21248K, used 4367K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
11    the space 21248K,  20% used [0x00000000fae00000, 0x00000000fb243dc0, 0x00000000fb243e00, 0x00000000fc2c0000)
12 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研究一下軟引用，測試代碼爲：

 1 /**
 2  * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7082471.html
 3  */
 4 @Test
 5 public void testSoftReference0() {
 6     System.out.println("**********軟引用測試**********");
 7         
 8     byte[] bytes = new byte[4 * _1MB];
 9     SoftReference<byte[]> sr = new SoftReference<byte[]>(bytes);
10     System.out.println("GC前：" + sr.get());
11         
12     bytes = null;
13         
14     System.gc();
15     System.out.println("GC後：" + sr.get());
16 }

一樣的new一個4M的byte數組，經過SoftReference構造方法放到SoftReference中。

這段代碼最值得注意的是第9行"bytes=null"這一句，若是不將bytes置空，那麼4M的byte數組還與強引用關聯着，內存不夠虛擬機將拋出異常而不會嘗試回收它；將bytes置空則不同，4M的byte數組失去了強引用，可是它又在SoftReference中，這意味着這個4M的byte數組目前僅僅與軟引用關聯。

運行一下程序，結果爲：

 1 **********軟引用測試**********
 2 GC前：[B@76404629
 3 [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] 
 4 GC後：[B@76404629
 5 Heap
 6  par new generation   total 9216K, used 284K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
 7   eden space 8192K,   3% used [0x00000000f9a00000, 0x00000000f9a47330, 0x00000000fa200000)
 8   from space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
 9   to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
10  tenured generation   total 10240K, used 5161K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
11    the space 10240K,  50% used [0x00000000fa400000, 0x00000000fa90a778, 0x00000000fa90a800, 0x00000000fae00000)
12  compacting perm gen  total 21248K, used 4367K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
13    the space 21248K,  20% used [0x00000000fae00000, 0x00000000fb243f10, 0x00000000fb244000, 0x00000000fc2c0000)
14 No shared spaces configured.

看到GC先後，bytes都是"[B@76404629"，很顯然4M的byte數組並無被回收。從內存空間來看，老年代中使用了5161K，和以前強引用測試是同樣的，證實了這一點。

那咱們怎麼能看到弱引用的回收呢？既然弱引用是發生在內存不夠以前，那隻須要不斷實例化byte數組，而後將之與軟引用關聯便可，代碼爲：

 1 /**
 2  * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7082471.html
 3  */
 4 @Test
 5 public void testSoftReference1() {
 6     System.out.println("**********軟引用測試**********");
 7             
 8     SoftReference<byte[]> sr0 = new SoftReference<byte[]>(new byte[4 * _1MB]);
 9     SoftReference<byte[]> sr1 = new SoftReference<byte[]>(new byte[4 * _1MB]);
10     SoftReference<byte[]> sr2 = new SoftReference<byte[]>(new byte[4 * _1MB]);
11     SoftReference<byte[]> sr3 = new SoftReference<byte[]>(new byte[4 * _1MB]);
12     SoftReference<byte[]> sr4 = new SoftReference<byte[]>(new byte[4 * _1MB]);
13     SoftReference<byte[]> sr5 = new SoftReference<byte[]>(new byte[4 * _1MB]);
14             
15     System.out.println(sr0.get());
16     System.out.println(sr1.get());
17     System.out.println(sr2.get());
18     System.out.println(sr3.get());
19     System.out.println(sr4.get());
20     System.out.println(sr5.get());
21 }

運行結果爲：

 1 **********軟引用測試**********
 2 [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] 
 3 [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] 
 4 [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] 
 5 [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] 
 6 [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] 
 7 [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] 
 8 null
 9 null
10 null
11 [B@4783165b
12 [B@6f30d50a
13 [B@6ef2bc8d
14 Heap
15  par new generation   total 9216K, used 4307K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
16   eden space 8192K,  52% used [0x00000000f9a00000, 0x00000000f9e32560, 0x00000000fa200000)
17   from space 1024K,   1% used [0x00000000fa200000, 0x00000000fa202978, 0x00000000fa300000)
18   to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
19  tenured generation   total 10240K, used 8975K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
20    the space 10240K,  87% used [0x00000000fa400000, 0x00000000facc3f40, 0x00000000facc4000, 0x00000000fae00000)
21  compacting perm gen  total 21248K, used 4366K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
22    the space 21248K,  20% used [0x00000000fae00000, 0x00000000fb2439e0, 0x00000000fb243a00, 0x00000000fc2c0000)
23 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用以將一個對象關聯到弱引用，弱引用的測試比較簡單，代碼爲：

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

我這裏不定義一個強引用直接關聯4M的byte數組（避免忘了將對象與強引用的關聯取消），這也是使用SoftReference、WeakReference時我我的比較推薦的作法。程序運行的結果爲：

 1 **********弱引用測試**********
 2 GC前：[B@21dd63a8
 3 [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] 
 4 GC後：null
 5 Heap
 6  par new generation   total 9216K, used 284K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
 7   eden space 8192K,   3% used [0x00000000f9a00000, 0x00000000f9a47318, 0x00000000fa200000)
 8   from space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
 9   to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
10  tenured generation   total 10240K, used 1065K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
11    the space 10240K,  10% used [0x00000000fa400000, 0x00000000fa50a6e8, 0x00000000fa50a800, 0x00000000fae00000)
12  compacting perm gen  total 21248K, used 4367K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
13    the space 21248K,  20% used [0x00000000fae00000, 0x00000000fb243dc8, 0x00000000fb243e00, 0x00000000fc2c0000)
14 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）去掉，代碼爲：

 1 /**
 2  * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7082471.html
 3  */
 4 @Test
 5 public void testReferenceQueue() {
 6     System.out.println("**********引用隊列測試**********\n");
 7         
 8     ReferenceQueue<byte[]> referenceQueue = new ReferenceQueue<byte[]>();
 9         
10     SoftReference<byte[]> sr0 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);
11     SoftReference<byte[]> sr1 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);
12     SoftReference<byte[]> sr2 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);
13     SoftReference<byte[]> sr3 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);
14     SoftReference<byte[]> sr4 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);
15     SoftReference<byte[]> sr5 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);
16         
17     System.out.println("**********軟引用關聯的對象展現**********");
18     System.out.println(sr0 + "---" + sr0.get());
19     System.out.println(sr1 + "---" + sr1.get());
20     System.out.println(sr2 + "---" + sr2.get());
21     System.out.println(sr3 + "---" + sr3.get());
22     System.out.println(sr4 + "---" + sr4.get());
23     System.out.println(sr5 + "---" + sr5.get());
24         
25     System.out.println("**********引用隊列中的SoftReference展現**********");
26     System.out.println(referenceQueue.poll());
27     System.out.println(referenceQueue.poll());
28     System.out.println(referenceQueue.poll());
29     System.out.println(referenceQueue.poll());
30     System.out.println(referenceQueue.poll());
31     System.out.println(referenceQueue.poll());
32 }

運行結果爲：

 1 **********引用隊列測試**********
 2 
 3 **********軟引用關聯的對象展現**********
 4 java.lang.ref.SoftReference@50ed0a5---null
 5 java.lang.ref.SoftReference@fa4033b---null
 6 java.lang.ref.SoftReference@58d01e82---null
 7 java.lang.ref.SoftReference@4783165b---[B@6f30d50a
 8 java.lang.ref.SoftReference@6ef2bc8d---[B@23905e3
 9 java.lang.ref.SoftReference@6db17b38---[B@1f10d1cb
10 **********引用隊列中的SoftReference展現**********
11 java.lang.ref.SoftReference@50ed0a5
12 java.lang.ref.SoftReference@fa4033b
13 java.lang.ref.SoftReference@58d01e82
14 null
15 null
16 null

看到因爲內存不夠，回收了前三個軟引用，且回收的三個軟引用內存地址都能對得上，這證實了上面的說法。

 

虛引用的研究

原本不許備寫虛引用的，由於比較簡單，虛引用惟一的目的只是跟蹤對象的回收。不事後面有網友朋友提出了問題，我本身看了一下，虛引用確實有一個容易混淆的地方，所以文章更新，最後一部分加上虛引用。

測試代碼爲：

 1 /**
 2  * @author 五月的倉頡http://www.cnblogs.com/xrq730/p/7082471.html
 3  */
 4 @Test
 5 public void testPhantomReference() {
 6     System.out.println("**********虛引用測試**********");
 7         
 8     ReferenceQueue<byte[]> referenceQueue = new ReferenceQueue<byte[]>();
 9         
10     byte[] bytes = new byte[4 * _1MB];
11     PhantomReference<byte[]> pr = new PhantomReference<byte[]>(bytes, referenceQueue);
12         
13     bytes = null;
14         
15     System.gc();
16         
17     System.out.println(referenceQueue.poll());
18     JdkUtil.sleep(100);
19     System.out.println(referenceQueue.poll());
20 }

第13行bytes置空，此時4M的byte數組只關聯了虛引用。這裏的重點代碼是第17行~第19行三行，代碼運行結果爲：

 1 **********虛引用測試**********
 2 [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] 
 3 null
 4 java.lang.ref.PhantomReference@6f30d50a
 5 Heap
 6  par new generation   total 9216K, used 365K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
 7   eden space 8192K,   4% used [0x00000000f9a00000, 0x00000000f9a5b768, 0x00000000fa200000)
 8   from space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
 9   to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
10  tenured generation   total 10240K, used 5163K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
11    the space 10240K,  50% used [0x00000000fa400000, 0x00000000fa90acf8, 0x00000000fa90ae00, 0x00000000fae00000)
12  compacting perm gen  total 21248K, used 4371K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
13    the space 21248K,  20% used [0x00000000fae00000, 0x00000000fb244e98, 0x00000000fb245000, 0x00000000fc2c0000)
14 No shared spaces configured.

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

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

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

以前咱們說了，虛引用惟一的做用是用於跟蹤對象的垃圾回收的，System.gc()方法調用的時候，4M的byte數組並無被立刻回收，System.gc()方法只是發出一個通知：建議觸發GC。

當4M的byte數組真正被回收的時候，虛引用加入引用隊列。所以一開始獲取隊列頭的時候隊列頭爲null，休眠100ms以後確保對象被回收，隊列頭中有虛引用。