Java四種引用---強、軟、弱、虛的知識點總結
前言
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