本文介紹對象的強、軟、弱和虛引用的概念、應用及其在UML中的表示。
1.對象的強、軟、弱和虛引用
在JDK 1.2以前的版本中,若一個對象不被任何變量引用,那麼程式就無法再使用這個對象。也就是說,隻有對象處于可觸及(reachable)狀态,程式才能使用它。從JDK 1.2版本開始,把對象的引用分為4種級别,進而使程式能更加靈活地控制對象的生命周期。這4種級别由高到低依次為:強引用、軟引用、弱引用和虛引用。圖1為對象應用類層次。
圖1
⑴強引用(StrongReference)
強引用是使用最普遍的引用。如果一個對象具有強引用,那垃圾回收器絕不會回收它。當記憶體空間不足,Java虛拟機甯願抛出OutOfMemoryError錯誤,使程式異常終止,也不會靠随意回收具有強引用的對象來解決記憶體不足的問題。
⑵軟引用(SoftReference)
如果一個對象隻具有軟引用,則記憶體空間足夠,垃圾回收器就不會回收它;如果記憶體空間不足了,就會回收這些對象的記憶體。隻要垃圾回收器沒有回收它,該對象就可以被程式使用。軟引用可用來實作記憶體敏感的高速緩存(下文給出示例)。
軟引用可以和一個引用隊列(ReferenceQueue)聯合使用,如果軟引用所引用的對象被垃圾回收器回收,Java虛拟機就會把這個軟引用加入到與之關聯的引用隊列中。
⑶弱引用(WeakReference)
弱引用與軟引用的差別在于:隻具有弱引用的對象擁有更短暫的生命周期。在垃圾回收器線程掃描它所管轄的記憶體區域的過程中,一旦發現了隻具有弱引用的對象,不管目前記憶體空間足夠與否,都會回收它的記憶體。不過,由于垃圾回收器是一個優先級很低的線程,是以不一定會很快發現那些隻具有弱引用的對象。
弱引用可以和一個引用隊列(ReferenceQueue)聯合使用,如果弱引用所引用的對象被垃圾回收,Java虛拟機就會把這個弱引用加入到與之關聯的引用隊列中。
⑷虛引用(PhantomReference)
“虛引用”顧名思義,就是形同虛設,與其他幾種引用都不同,虛引用并不會決定對象的生命周期。如果一個對象僅持有虛引用,那麼它就和沒有任何引用一樣,在任何時候都可能被垃圾回收器回收。
虛引用主要用來跟蹤對象被垃圾回收器回收的活動。虛引用與軟引用和弱引用的一個差別在于:虛引用必須和引用隊列 (ReferenceQueue)聯合使用。當垃圾回收器準備回收一個對象時,如果發現它還有虛引用,就會在回收對象的記憶體之前,把這個虛引用加入到與之 關聯的引用隊列中。
ReferenceQueue queue = new ReferenceQueue ();
PhantomReference pr = new PhantomReference (object, queue);
程式可以通過判斷引用隊列中是否已經加入了虛引用,來了解被引用的對象是否将要被垃圾回收。如果程式發現某個虛引用已經被加入到引用隊列,那麼就可以在所引用的對象的記憶體被回收之前采取必要的行動。
2.對象可及性的判斷
在很多時候,一個對象并不是從根集直接引用的,而是一個對象被其他對象引用,甚至同時被幾個對象所引用,進而構成一個以根集為頂的樹形結構。如圖2所示
在這個樹形的引用鍊中,箭頭的方向代表了引用的方向,所指向的對象是被引用對象。由圖可以看出,從根集到一個對象可以由很多條路徑。比如到達對象5的路徑就有①-⑤,③-⑦兩條路徑。由此帶來了一個問題,那就是某個對象的可及性如何判斷:
◆單條引用路徑可及性判斷:在這條路徑中,最弱的一個引用決定對象的可及性。
◆多條引用路徑可及性判斷:幾條路徑中,最強的一條的引用決定對象的可及性。
比如,我們假設圖2中引用①和③為強引用,⑤為軟引用,⑦為弱引用,對于對象5按照這兩個判斷原則,路徑①-⑤取最弱的引用⑤,是以該路徑對對象5的引用為軟引用。同樣,③-⑦為弱引用。在這兩條路徑之間取最強的引用,于是對象5是一個軟可及對象。
3.使用軟引用建構敏感資料的緩存
3.1 為什麼需要使用軟引用
首先,我們看一個雇員資訊查詢系統的執行個體。我們将使用一個Java語言實作的雇員資訊查詢系統查詢存儲在磁盤檔案或者資料庫中的雇員人事檔案資訊。作為一個使用者,我們完全有可能需要回頭去檢視幾分鐘甚至幾秒鐘前檢視過的雇員檔案資訊(同樣,我們在浏覽WEB頁面的時候也經常會使用“後退”按鈕)。這時我們通常會有兩種程式實作方式:一種是把過去檢視過的雇員資訊儲存在記憶體中,每一個存儲了雇員檔案資訊的Java對象的生命周期貫穿整個應用程式始終;另一種是當使用者開始檢視其他雇員的檔案資訊的時候,把存儲了目前所檢視的雇員檔案資訊的Java對象結束引用,使得垃圾收集線程可以回收其所占用的記憶體空間,當使用者再次需要浏覽該雇員的檔案資訊的時候,重新建構該雇員的資訊。很顯然,第一種實作方法将造成大量的記憶體浪費,而第二種實作的缺陷在于即使垃圾收集線程還沒有進行垃圾收集,包含雇員檔案資訊的對象仍然完好地儲存在記憶體中,應用程式也要重新建構一個對象。我們知道,通路磁盤檔案、通路網絡資源、查詢資料庫等操作都是影響應用程式執行性能的重要因素,如果能重新擷取那些尚未被回收的Java對象的引用,必将減少不必要的通路,大大提高程式的運作速度。
3.2 如何使用軟引用
SoftReference的特點是它的一個執行個體儲存對一個Java對象的軟引用,該軟引用的存在不妨礙垃圾收集線程對該Java對象的回收。也就是說,一旦SoftReference儲存了對一個Java對象的軟引用後,在垃圾線程對這個Java對象回收前,SoftReference類所提供的get()方法傳回Java對象的強引用。另外,一旦垃圾線程回收該Java對象之後,get()方法将傳回null。
看下面代碼:
MyObject aRef = new?MyObject();
SoftReference aSoftRef=new SoftReference(aRef);
此時,對于這個MyObject對象,有兩個引用路徑,一個是來自SoftReference對象的軟引用,一個來自變量aReference的強引用,是以這個MyObject對象是強可及對象。
随即,我們可以結束aReference對這個MyObject執行個體的強引用:
aRef = null;
此後,這個MyObject對象成為了軟可及對象。如果垃圾收集線程進行記憶體垃圾收集,并不會因為有一個SoftReference對該對象的引用而始終保留該對象。Java虛拟機的垃圾收集線程對軟可及對象和其他一般Java對象進行了差別對待:軟可及對象的清理是由垃圾收集線程根據其特定算法按照記憶體需求決定的。也就是說,垃圾收集線程會在虛拟機抛出OutOfMemoryError之前回收軟可及對象,而且虛拟機會盡可能優先回收長時間閑置不用的軟可及對象,對那些剛剛建構的或剛剛使用過的“新”軟可反對象會被虛拟機盡可能保留。在回收這些對象之前,我們可以通過:
MyObject anotherRef=(MyObject)aSoftRef.get();
重新獲得對該執行個體的強引用。而回收之後,調用get()方法就隻能得到null了。
3.3 使用ReferenceQueue清除失去了軟引用對象的SoftReference
作為一個Java對象,SoftReference對象除了具有儲存軟引用的特殊性之外,也具有Java對象的一般性。是以,當軟可及對象被回收之後,雖然這個SoftReference對象的get()方法傳回null,但這個SoftReference對象已經不再具有存在的價值,需要一個适當的清除機制,避免大量SoftReference對象帶來的記憶體洩漏。在java.lang.ref包裡還提供了ReferenceQueue。如果在建立SoftReference對象的時候,使用了一個ReferenceQueue對象作為參數提供給SoftReference的構造方法,如:
ReferenceQueue queue = new?ReferenceQueue();
SoftReference?ref=new?SoftReference(aMyObject, queue);
那麼當這個SoftReference所軟引用的aMyOhject被垃圾收集器回收的同時,ref所強引用的SoftReference對象被列入ReferenceQueue。也就是說,ReferenceQueue中儲存的對象是Reference對象,而且是已經失去了它所軟引用的對象的Reference對象。另外從ReferenceQueue這個名字也可以看出,它是一個隊列,當我們調用它的poll()方法的時候,如果這個隊列中不是空隊列,那麼将傳回隊列前面的那個Reference對象。
在任何時候,我們都可以調用ReferenceQueue的poll()方法來檢查是否有它所關心的非強可及對象被回收。如果隊列為空,将傳回一個null,否則該方法傳回隊列中前面的一個Reference對象。利用這個方法,我們可以檢查哪個SoftReference所軟引用的對象已經被回收。于是我們可以把這些失去所軟引用的對象的SoftReference對象清除掉。常用的方式為:
SoftReference ref = null;
while ((ref = (EmployeeRef) q.poll()) != null) {
// 清除ref
}
了解了ReferenceQueue的工作機制之後,我們就可以開始構造一個Java對象的高速緩存器了。
3.4通過軟可及對象重獲方法實作Java對象的高速緩存
利用Java2平台垃圾收集機制的特性以及前述的垃圾對象重獲方法,我們通過一個雇員資訊查詢系統的小例子來說明如何建構一種高速緩存器來避免重複建構同一個對象帶來的性能損失。我們将一個雇員的檔案資訊定義為一個Employee類:
public class Employee {
private String id;// 雇員的辨別号碼
private String name;// 雇員姓名
private String department;// 該雇員所在部門
private String Phone;// 該雇員聯系電話
private int salary;// 該雇員薪資
private String origin;// 該雇員資訊的來源
// 構造方法
public Employee(String id) {
this.id = id;
getDataFromlnfoCenter();
// 到資料庫中取得雇員資訊
private void getDataFromlnfoCenter() {
// 和資料庫建立連接配接井查詢該雇員的資訊,将查詢結果指派
// 給name,department,plone,salary等變量
// 同時将origin指派為"From DataBase"
……
這個Employee類的構造方法中我們可以預見,如果每次需要查詢一個雇員的資訊。哪怕是幾秒中之前剛剛查詢過的,都要重新建構一個執行個體,這是需要消耗很多時間的。下面是一個對Employee對象進行緩存的緩存器的定義:
import java.lang.ref.ReferenceQueue;
import java.lang.ref.SoftReference;
import java.util.Hashtable;
public class EmployeeCache {
static private EmployeeCache cache;// 一個Cache執行個體
private Hashtable< String,EmployeeRef> employeeRefs;// 用于Chche内容的存儲
private ReferenceQueue< Employee> q;// 垃圾Reference的隊列
// 繼承SoftReference,使得每一個執行個體都具有可識别的辨別。
private class EmployeeRef extends SoftReference< Employee> {
private String _key = "";
public EmployeeRef(Employee em, ReferenceQueue< Employee> q) {
super(em, q);
_key = em.getID();
}
}
// 建構一個緩存器執行個體
private EmployeeCache() {
employeeRefs = new Hashtable<String,EmployeeRef>();
q = new ReferenceQueue<Employee>();
}
// 取得緩存器執行個體
public static EmployeeCache getInstance() {
if (cache == null) {
cache = new EmployeeCache();
return cache;
// 以軟引用的方式對一個Employee對象的執行個體進行引用并儲存該引用
private void cacheEmployee(Employee em) {
cleanCache();// 清除垃圾引用
EmployeeRef ref = new EmployeeRef(em, q);
employeeRefs.put(em.getID(), ref);
// 依據所指定的ID号,重新擷取相應Employee對象的執行個體
public Employee getEmployee(String ID) {
Employee em = null;
// 緩存中是否有該Employee執行個體的軟引用,如果有,從軟引用中取得。
if (employeeRefs.containsKey(ID)) {
EmployeeRef ref = (EmployeeRef) employeeRefs.get(ID);
em = (Employee) ref.get();
}
// 如果沒有軟引用,或者從軟引用中得到的執行個體是null,重新建構一個執行個體,
// 并儲存對這個建立執行個體的軟引用
if (em == null) {
em = new Employee(ID);
System.out.println("Retrieve From EmployeeInfoCenter. ID=" + ID);
this.cacheEmployee(em);
return em;
private void cleanCache() {
EmployeeRef ref = null;
while ((ref = (EmployeeRef) q.poll()) != null) {
employeeRefs.remove(ref._key);
// 清除Cache内的全部内容
public void clearCache() {
cleanCache();
employeeRefs.clear();
System.gc();
System.runFinalization();
注:原來ReferenceQueue起到一個監聽器的效果,當發現SoftReference.get()方法傳回的是null值時,就會将SoftReference注冊到自己裡面隊列裡,當我們調用ReferenceQueue的poll()方法時,傳回并删除該SoftReference。
轉自:http://puretech.iteye.com/blog/2008663
在Java裡, 當一個對象o被建立時, 它被放在Heap裡. 當GC運作的時候, 如果發現沒有任何引用指向o, o就會被回收以騰出記憶體空間. 或者換句話說, 一個對象被回收, 必須滿足兩個條件: 1)沒有任何引用指向它 2)GC被運作.
在現實情況寫代碼的時候, 我們往往通過把所有指向某個對象的referece置空來保證這個對象在下次GC運作的時候被回收 (可以用java -verbose:gc來觀察gc的行為)
Java代碼
- Object c = new Car();
- c=null;
但是, 手動置空對象對于程式員來說, 是一件繁瑣且違背自動回收的理念的. 對于簡單的情況, 手動置空是不需要程式員來做的, 因為在java中, 對于簡單對象, 當調用它的方法執行完畢後, 指向它的引用會被從stack中popup, 是以他就能在下一次GC執行時被回收了.
但是, 也有特殊例外. 當使用cache的時候, 由于cache的對象正是程式運作需要的, 那麼隻要程式正在運作, cache中的引用就不會被GC給(或者說, cache中的reference擁有了和主程式一樣的life cycle). 那麼随着cache中的reference越來越多, GC無法回收的object也越來越多, 無法被自動回收. 當這些object需要被回收時, 回收這些object的任務隻有交給程式編寫者了. 然而這卻違背了GC的本質(自動回收可以回收的objects).
是以, java中引入了weak reference. 相對于前面舉例中的strong reference:
- Object c = new Car(); //隻要c還指向car object, car object就不會被回收
當一個對象僅僅被weak reference指向, 而沒有任何其他strong reference指向的時候, 如果GC運作, 那麼這個對象就會被回收. weak reference的文法是:
- WeakReference<Car> weakCar = new WeakReference(Car)(car);
當要獲得weak reference引用的object時, 首先需要判斷它是否已經被回收:
- weakCar.get();
如果此方法為空, 那麼說明weakCar指向的對象已經被回收了.
下面來看一個例子:
-
1 package weakreference; 2 /**
3 * @author wison
4 */
5 public class Car {
6 private double price;
7 private String colour;
8
9 public Car(double price, String colour){
10 this.price = price;
11 this.colour = colour;
12 }
13
14 public double getPrice() {
15 return price;
16 }
17 public void setPrice(double price) {
18 this.price = price;
19 }
20 public String getColour() {
21 return colour;
22 }
23 public void setColour(String colour) {
24 this.colour = colour;
25 }
26
27 public String toString(){
28 return colour +"car costs $"+price;
29 }
30
31 }
-
1 package weakreference; 2
3 import java.lang.ref.WeakReference;
4
5 /**
6 * @author wison
7 */
8 public class TestWeakReference {
9
10
11 public static void main(String[] args) {
12
13 Car car = new Car(22000,"silver");
14 WeakReference<Car> weakCar = new WeakReference<Car>(car);
15
16 int i=0;
17
18 while(true){
19 if(weakCar.get()!=null){
20 i++;
21 System.out.println("Object is alive for "+i+" loops - "+weakCar);
22 }else{
23 System.out.println("Object has been collected.");
24 break;
25 }
26 }
27 }
28
29 }
在上例中, 程式運作一段時間後, 程式列印出"Object has been collected." 說明, weak reference指向的對象的被回收了.
值得注意的一點, 即使有car引用指向對象, 且car是一個strong reference, weak reference weakCar指向的對象仍然被回收了. 這是因為java的編譯器在發現進入while循環之後, car已經沒有被使用了, 是以進行了優化(将其置空?).
當把TestWeakReference.java修改為:
-
19 System.out.println("here is the strong reference 'car' "+car);//use the strong reference in the while loop
20 if(weakCar.get()!=null){
21 i++;
22 System.out.println("Object is alive for "+i+" loops - "+weakCar);
23 }else{
24 System.out.println("Object has been collected.");
25 break;
26 }
27 }
28 }
29
30 }
weak reference指向的object就不會被回收了. 因為還有一個strong reference car指向它.
* WeakReference的一個特點是它何時被回收是不可确定的, 因為這是由GC運作的不确定性所确定的. 是以, 一般用weak reference引用的對象是有價值被cache, 而且很容易被重新被建構, 且很消耗記憶體的對象.
ReferenceQueue
在weak reference指向的對象被回收後, weak reference本身其實也就沒有用了. java提供了一個ReferenceQueue來儲存這些所指向的對象已經被回收的reference. 用法是在定義WeakReference的時候将一個ReferenceQueue的對象作為參數傳入構造函數.
其他類型的references
-SoftReference
soft reference和weak reference一樣, 但被GC回收的時候需要多一個條件: 當系統記憶體不足時(GC是如何判定系統記憶體不足? 是否有參數可以配置這個threshold?), soft reference指向的object才會被回收. 正因為有這個特性, soft reference比weak reference更加适合做cache objects的reference. 因為它可以盡可能的retain cached objects, 減少重建他們所需的時間和消耗.
-phantomReference
這個還沒想到應用場景, 就先不說了. 有人在實踐中用到了的話, 歡迎分享.
WeakHashMap
to be continued