深入Java(二)：Java中的強引用、軟引用、弱引用、幻像引用( 虛引用)
在Java語言中，除了基本資料型別外，其他的都是指向各類物件的物件引用；Java中根據其生命週期的長短，將引用分為4類。
1 強引用
特點：我們平常典型編碼Object obj = new Object()中的obj就是強引用。通過關鍵字new建立的物件所關聯的引用就是強引用。 當JVM記憶體空間不足，JVM寧願丟擲OutOfMemoryError執行時錯誤（OOM），使程式異常終止，也不會靠隨意回收具有強引用的“存活”物件來解決記憶體不足的問題。對於一個普通的物件，如果沒有其他的引用關係，只要超過了引用的作用域或者顯式地將相應（強）引用賦值為 null，就是可以被垃圾收集的了，具體回收時機還是要看垃圾收集策略。
2 軟引用
特點：軟引用通過SoftReference類實現。 軟引用的生命週期比強引用短一些。只有當 JVM 認為記憶體不足時，才會去試圖回收軟引用指向的物件：即JVM 會確保在丟擲 OutOfMemoryError 之前，清理軟引用指向的物件。軟引用可以和一個引用佇列（ReferenceQueue）聯合使用，如果軟引用所引用的物件被垃圾回收器回收，Java虛擬機器就會把這個軟引用加入到與之關聯的引用佇列中。後續，我們可以呼叫ReferenceQueue的poll()方法來檢查是否有它所關心的物件被回收。如果佇列為空，將返回一個null,否則該方法返回佇列中前面的一個Reference物件。
應用場景：軟引用通常用來實現記憶體敏感的快取。如果還有空閒記憶體，就可以暫時保留快取，當記憶體不足時清理掉，這樣就保證了使用快取的同時，不會耗盡記憶體。
3 弱引用
弱引用通過WeakReference類實現。 弱引用的生命週期比軟引用短。在垃圾回收器執行緒掃描它所管轄的記憶體區域的過程中，一旦發現了具有弱引用的物件，不管當前記憶體空間足夠與否，都會回收它的記憶體。由於垃圾回收器是一個優先順序很低的執行緒，因此不一定會很快回收弱引用的物件。弱引用可以和一個引用佇列（ReferenceQueue）聯合使用，如果弱引用所引用的物件被垃圾回收，Java虛擬機器就會把這個弱引用加入到與之關聯的引用佇列中。
應用場景：弱應用同樣可用於記憶體敏感的快取。
4 虛引用
特點：虛引用也叫幻象引用，通過PhantomReference類來實現。無法通過虛引用訪問物件的任何屬性或函式。幻象引用僅僅是提供了一種確保物件被 finalize 以後，做某些事情的機制。如果一個物件僅持有虛引用，那麼它就和沒有任何引用一樣，在任何時候都可能被垃圾回收器回收。虛引用必須和引用佇列 （ReferenceQueue）聯合使用。當垃圾回收器準備回收一個物件時，如果發現它還有虛引用，就會在回收物件的記憶體之前，把這個虛引用加入到與之關聯的引用佇列中。
ReferenceQueue queue = new ReferenceQueue ();
PhantomReference pr = new PhantomReference (object, queue);
程式可以通過判斷引用佇列中是否已經加入了虛引用，來了解被引用的物件是否將要被垃圾回收。如果程式發現某個虛引用已經被加入到引用佇列，那麼就可以在所引用的物件的記憶體被回收之前採取一些程式行動。
應用場景：可用來跟蹤物件被垃圾回收器回收的活動，當一個虛引用關聯的物件被垃圾收集器回收之前會收到一條系統通知。
診斷 JVM 引用情況
如果你懷疑應用存在引用（或 finalize）導致的回收問題，可以有很多工具或者選項可供選擇，比如 HotSpot JVM 自身便提供了明確的選項（PrintReferenceGC）去獲取相關資訊，我指定了下面選項去使用 JDK 8 執行一個樣例應用：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintReferenceGC
這是 JDK 8 使用 ParrallelGC 收集的垃圾收集日誌，各種引用數量非常清晰。
0.403: [GC (Allocation Failure) 0.871: [SoftReference, 0 refs, 0.0000393 secs]0.871: [WeakReference, 8 refs, 0.0000138 secs]0.871: [FinalReference, 4 refs, 0.0000094 secs]0.871: [PhantomReference, 0 refs, 0 refs, 0.0000085 secs]0.871: [JNI Weak Reference, 0.0000071 secs][PSYoungGen: 76272K->10720K(141824K)] 128286K->128422K(316928K), 0.4683919 secs] [Times: user=1.17 sys=0.03, real=0.47 secs]
注意：JDK 9 對 JVM 和垃圾收集日誌進行了廣泛的重構，類似 PrintGCTimeStamps 和 PrintReferenceGC 已經不再存在，我在專欄後面的垃圾收集主題裡會更加系統的闡述。