前言

1.本文屬於知識點總結篇,基本內容以概念+原始碼分析+流程圖為主.

2.本文大多數概念,屬於站在巨人肩膀上整合而成,為了自己更好的複習和大眾對於這塊知識的瞭解.

3.本人學識尚淺,對於文章中如果有描述有誤的地方,還請大家及時通知,然後博主及時進行更改,以免誤導他人.

4.本博文的行進思路,會以導讀為主,還請大家多多參閱.

導讀

本文會按照以下思路進行：

（1）Java的四種物件引用的基本概念

（2）四種物件引用的差異對比

（3）物件可及性的判斷以及與垃圾回收機制的關係

（4）引用佇列ReferenceQueue的介紹

（5）WeakHashMap的相關介紹

Java的四種物件引用的基本概念

從JDK1.2版本開始，把物件的引用分為四種級別，從而使程式更加靈活的控制物件的生命週期。這四種級別由高到低依次為：強引用、軟引用、弱引用和虛引用。

1、強引用

Object obj =new Object();

上述Object這類物件就具有強引用，屬於不可回收的資源，垃圾回收器絕不會回收它。當記憶體空間不足，Java虛擬機器寧願丟擲OutOfMemoryError錯誤，使程式異常終止，也不會靠回收具有強引用的物件，來解決記憶體不足的問題。

值得注意的是：如果想中斷或者回收強引用物件，可以顯式地將引用賦值為null，這樣的話JVM就會在合適的時間，進行垃圾回收。

下圖是堆區的記憶體示意圖，分為新生代，老生代，而垃圾回收主要也是在這部分割槽域中進行。

2、軟引用（SoftReference）

如果一個物件只具有軟引用，那麼它的性質屬於可有可無的那種。如果此時記憶體空間足夠，垃圾回收器就不會回收它，如果記憶體空間不足了，就會回收這些物件的記憶體。只要垃圾回收器沒有回收它，該物件就可以被程式使用。

軟引用可用來實現記憶體敏感的告訴快取。軟引用可以和一個引用佇列聯合使用，如果軟體用所引用的物件被垃圾回收，Java虛擬機器就會把這個軟引用加入到與之關聯的引用佇列中。

        Object obj = new Object();
        ReferenceQueue queue = new
 
 ReferenceQueue();
        SoftReference reference = new SoftReference(obj, queue);
        //強引用物件滯空，保留軟引用
        obj = null;

當記憶體不足時，軟引用物件被回收時，reference.get()為null，此時軟引用物件的作用已經發揮完畢，這時將其新增進ReferenceQueue 佇列中

如果要判斷哪些軟引用物件已經被清理：

        SoftReference ref = null;
        while ((ref = (SoftReference) queue.poll()) != null) {
            //清除軟引用物件
        }

3、弱引用(WeakReference)

如果一個物件具有弱引用，那其的性質也是可有可無的狀態。

而弱引用和軟引用的區別在於：弱引用的物件擁有更短的生命週期，只要垃圾回收器掃描到它，不管記憶體空間充足與否，都會回收它的記憶體。

同樣的弱引用也可以和引用佇列一起使用。

        Object obj = new Object();
        ReferenceQueue queue = new ReferenceQueue();
        WeakReference reference = new WeakReference(obj, queue);
        //強引用物件滯空，保留軟引用
        obj = null;

4、虛引用（PhantomReference）

虛引用和前面的軟引用、弱引用不同，它並不影響物件的生命週期。如果一個物件與虛引用關聯，則跟沒有引用與之關聯一樣，在任何時候都可能被垃圾回收器回收。

注意：虛引用必須和引用佇列關聯使用，當垃圾回收器準備回收一個物件時，如果發現它還有虛引用，就會把這個虛引用加入到與之關聯的引用佇列中。

程式可以通過判斷引用佇列中是否已經加入了虛引用，來了解被引用的物件是否將要被垃圾回收。如果程式發現某個虛引用已經被加入到引用佇列，那麼就可以在所引用的物件的記憶體被回收之前採取必要的行動。

        Object obj = new Object();
        ReferenceQueue queue = new ReferenceQueue();
        PhantomReference reference = new PhantomReference(obj, queue);
        //強引用物件滯空，保留軟引用
        obj = null;

引用總結

1.對於強引用，平時在編寫程式碼時會經常使用。

2.而其他三種類型的引用，使用得最多就是軟引用和弱引用，這兩種既有相似之處又有區別，他們都來描述非必須物件。

3.被軟引用關聯的物件只有在記憶體不足時才會被回收，而被弱引用關聯的物件在JVM進行垃圾回收時總會被回收。

四種物件引用的差異對比

Java中4種引用的級別由高到低依次為：

強引用 > 軟引用 > 弱引用 > 虛引用

垃圾回收時對比：

物件可及性的判斷

在很多的時候，一個物件並不是從根集直接引用的，而是一個物件被其他物件引用，甚至同時被幾個物件所引用，從而構成一個以根集為頂的樹形結構。

在這個樹形的引用鏈中，箭頭的方向代表了引用的方向，所指向的物件是被引用物件。由圖可以看出，從根集到一個物件可以由很多條路徑。

比如到達物件5的路徑就有① -> ⑤，③ ->⑦兩條路徑。由此帶來了一個問題，那就是某個物件的可及性如何判斷：

（1）單條引用路徑可及性判斷：

在這條路徑中，最弱的一個引用決定物件的可及性。

（2）多條引用路徑可及性判斷：

幾條路徑中，最強的一條的引用決定物件的可及性。

比如，我們假設圖2中引用①和③為強引用，⑤為軟引用，⑦為弱引用，對於物件5按照這兩個判斷原則，路徑①-⑤取最弱的引用⑤，因此該路徑對物件5的引用為軟引用。同樣，③-⑦為弱引用。在這兩條路徑之間取最強的引用，於是物件5是一個軟可及物件。

比較容易理解的是Java垃圾回收器會優先清理可及強度低的物件

另外兩個重要的點：

強可達的物件一定不會被清理

JVM保證丟擲out of memory之前，清理所有的軟引用物件

最後總結成一張表格：

引用型別	被垃圾回收時間	用途	生存時間
強引用	從來不會	物件的一般狀態	JVM停止執行時終止
軟引用	在記憶體不足時	物件快取	記憶體不足時終止
弱引用	在垃圾回收時	物件快取	垃圾回收時終止
虛引用	Unkonwn	Unkonwn	Unkonwn

引用佇列ReferenceQueue的介紹

引用佇列配合Reference的子類等使用,當引用物件所指向的物件被垃圾回收後,該Reference則被追加到引用佇列的末尾.

ReferenceQueue原始碼分析(簡要)

(1)ReferenceQueue是一個連結串列,這兩個指標代表著頭和尾

    private Reference<? extends T> head = null;
    private Reference<? extends T> tail = null;

(2)下面看下其共有的方法

取出元素:

Reference<? extends T> ReferenceQueue#poll()

如果Reference指向的物件存在則返回null,否則返回這個Reference

    public Reference<? extends T> poll() {
        synchronized (lock) {
            if (head == null)
                return null;

            return reallyPollLocked();
        }
    }

下面是具體將Reference取出的方法:

    private Reference<? extends T> reallyPollLocked() {
        if (head != null) {
            Reference<? extends T> r = head;
            if (head == tail) {
                tail = null;
                head = null;
            } else {
                head = head.queueNext;
            }

            //更新連結串列,將sQueueNextUnenqueued這個虛引用物件加入,並且已經表明該Reference已經被移除了,並且取出.
            r.queueNext = sQueueNextUnenqueued;
            return r;
        }

        return null;
    }

取出元素,如果佇列屬於空佇列,那麼久阻塞到其有元素為止

Reference<? extends T> ReferenceQueue#remove()

和remove()的區別是,設定一個阻塞時間

Reference<? extends T> ReferenceQueue#remove(long timeout)

具體實現

   public Reference<? extends T> remove(long timeout)
        throws IllegalArgumentException, InterruptedException
    {
        if (timeout < 0) {
            throw new IllegalArgumentException("Negative timeout value");
        }
        synchronized (lock) {
            Reference<? extends T> r = reallyPollLocked();
            if (r != null) return r;
            long start = (timeout == 0) ? 0 : System.nanoTime();
            //阻塞的具體實現過程,以及通過時間來控制的阻塞
            for (;;) {
                lock.wait(timeout);
                r = reallyPollLocked();
                if (r != null) return r;
                if (timeout != 0) {
                    long end = System.nanoTime();
                    timeout -= (end - start) / 1000_000;
                    if (timeout <= 0) return null;
                    start = end;
                }
            }
        }
    }

WeakHashMap的相關介紹

在Java集合中有一種特殊的Map型別即WeakHashMap,在這種Map中存放了鍵物件的弱引用,當一個鍵物件被垃圾回收器回收時,那麼相應的值物件的引用會從Map中刪除.

WeakHashMap能夠節約儲存空間,可用來快取那些非必須存在的資料.

而WeakHashMap是主要通過expungeStaleEntries()這個方法來實現的,而WeakHashMap也內建了一個ReferenceQueue,來獲取鍵物件的引用情況.

這個方法,相當於遍歷ReferenceQueue然後,將已經被回收的鍵物件,對應的值物件滯空.

    private void expungeStaleEntries() {
        for (Object x; (x = queue.poll()) != null; ) {
            synchronized (queue) {
                @SuppressWarnings("unchecked")
                    Entry<K,V> e = (Entry<K,V>) x;
                int i = indexFor(e.hash, table.length);

                Entry<K,V> prev = table[i];
                Entry<K,V> p = prev;
                while (p != null) {
                    Entry<K,V> next = p.next;
                    if (p == e) {
                        if (prev == e)
                            table[i] = next;
                        else
                            prev.next = next;
                        // Must not null out e.next;
                        // stale entries may be in use by a HashIterator
                        //通過滯空,來幫助垃圾回收
                        e.value = null; 
                        size--;
                        break;
                    }
                    prev = p;
                    p = next;
                }
            }
        }
    }

而且需要注意的是:

expungeStaleEntries()並不是自動呼叫的,需要外部對WeakHashMap物件進行查詢或者操作,才會進行自動釋放的操作.如下我們看個例子:

下面例子是不斷的增加1000*1000容量的WeakHashMap存入List中

public static void main(String[] args) throws Exception {  

    List<WeakHashMap<byte[][], byte[][]>> maps = new ArrayList<WeakHashMap<byte[][], byte[][]>>();  

    for (int i = 0; i < 1000; i++) {  
        WeakHashMap<byte[][], byte[][]> d = new WeakHashMap<byte[][], byte[][]>();  
        d.put(new byte[1000][1000], new byte[1000][1000]);  
        maps.add(d);  
        System.gc();  
        System.err.println(i);  
    } 
}  

由於Java預設記憶體是64M，所以再不改變記憶體引數的情況下，該測試跑不了幾步迴圈就記憶體溢位了。果不其然，WeakHashMap這個時候並沒有自動幫我們釋放不用的記憶體。

public static void main(String[] args) throws Exception {  

        List<WeakHashMap<byte[][], byte[][]>> maps = new ArrayList<WeakHashMap<byte[][], byte[][]>>();  

        for (int i = 0; i < 1000; i++) {  
            WeakHashMap<byte[][], byte[][]> d = new WeakHashMap<byte[][], byte[][]>();  
            d.put(new byte[1000][1000], new byte[1000][1000]);  
            maps.add(d);  
            System.gc();  
            System.err.println(i);  

            for (int j = 0; j < i; j++) {  
                System.err.println(j+  " size" + maps.get(j).size());  
            }  
        }  
    }  

而通過訪問WeakHashMap的size()方法,這些就可以跑通了.

這樣就能夠說明了WeakHashMap並不是自動進行鍵值的垃圾回收操作的,而需要做對WeakHashMap的訪問操作這時候才進行對鍵物件的垃圾回收清理.

WeakHashMap的神話 這篇帖子很棒,通過討論WeakHashMap的回收問題,拋磚引玉.

來一張總結圖:

由圖可以看出,WeakHashMap中只要呼叫其操作方法,那麼就會呼叫其expungeStaleEntries().

參考文章

1.Java 的四種引用方式 - 空谷幽瀾
http://www.cnblogs.com/huajiezh/p/5835618.html

2.Java 的四種引用 - OYK
http://www.cnblogs.com/-OYK/archive/2011/10/24/2222874.html

3.Java 7之基礎 - 強引用、弱引用、軟引用、虛引用
http://blog.csdn.net/mazhimazh/article/details/19752475

4.Java魔法堂：四種引用型別、ReferenceQueue和WeakHashMap
http://www.cnblogs.com/fsjohnhuang/p/4268411.html

5.WeakHashMap的神話
http://www.iteye.com/topic/587995