關於system.gc()與finalize()方法
注:本文的目的並不是鼓勵使用finalize方法,而是大致理清其作用、問題以及GC執行finalize的過程。
1. finalize的作用
- finalize()是Object的protected方法,子類可以覆蓋該方法以實現資源清理工作,GC在回收物件之前呼叫該方法。
- finalize()與C++中的解構函式不是對應的。C++中的解構函式呼叫的時機是確定的(物件離開作用域或delete掉),但Java中的finalize的呼叫具有不確定性
- 不建議用finalize方法完成“非記憶體資源”的清理工作,但建議用於:① 清理本地物件(通過JNI建立的物件);② 作為確保某些非記憶體資源(如Socket、檔案等)釋放的一個補充:在finalize方法中顯式呼叫其他資源釋放方法。其原因可見下文[finalize的問題]
2. finalize的問題
- 一些與finalize相關的方法,由於一些致命的缺陷,已經被廢棄了,如System.runFinalizersOnExit()方法、Runtime.runFinalizersOnExit()方法
- System.gc()與System.runFinalization()方法增加了finalize方法執行的機會,但不可盲目依賴它們
- Java語言規範並不保證finalize方法會被及時地執行、而且根本不會保證它們會被執行
- finalize方法可能會帶來效能問題。因為JVM通常在單獨的低優先順序執行緒中完成finalize的執行
- 物件再生問題:finalize方法中,可將待回收物件賦值給GC Roots可達的物件引用,從而達到物件再生的目的
- finalize方法至多由GC執行一次(使用者當然可以手動呼叫物件的finalize方法,但並不影響GC對finalize的行為)
3. finalize的執行過程(生命週期)
- 首先,大致描述一下finalize流程:當物件變成(GC Roots)不可達時,GC會判斷該物件是否覆蓋了finalize方法,若未覆蓋,則直接將其回收。否則,若物件未執行過finalize方法,將其放入F-Queue佇列,由一低優先順序執行緒執行該佇列中物件的finalize方法。執行finalize方法完畢後,GC會再次判斷該物件是否可達,若不可達,則進行回收,否則,物件“復活”。
- 具體的finalize流程:
物件可由兩種狀態,涉及到兩類狀態空間,一是終結狀態空間 F = {unfinalized, finalizable, finalized};二是可達狀態空間 R = {reachable, finalizer-reachable, unreachable}。各狀態含義如下:
- unfinalized: 新建物件會先進入此狀態,GC並未準備執行其finalize方法,因為該物件是可達的
- finalizable: 表示GC可對該物件執行finalize方法,GC已檢測到該物件不可達。正如前面所述,GC通過F-Queue佇列和一專用執行緒完成finalize的執行
- finalized: 表示GC已經對該物件執行過finalize方法
- reachable: 表示GC Roots引用可達
- finalizer-reachable(f-reachable):表示不是reachable,但可通過某個finalizable物件可達
- unreachable:物件不可通過上面兩種途徑可達
狀態變遷圖:
變遷說明:
1. 新建物件首先處於[reachable, unfinalized]狀態(A)
2. 隨著程式的執行,一些引用關係會消失,導致狀態變遷,從reachable狀態變遷到f-reachable(B, C, D)或unreachable(E, F)狀態
3. 若JVM檢測到處於unfinalized狀態的物件變成f-reachable或unreachable,JVM會將其標記為finalizable狀態(G,H)。若物件原處於[unreachable, unfinalized]狀態,則同時將其標記為f-reachable(H)。
4. 在某個時刻,JVM取出某個finalizable物件,將其標記為finalized並在某個執行緒中執行其finalize方法。由於是在活動執行緒中引用了該物件,該物件將變遷到(reachable, finalized)狀態(K或J)。該動作將影響某些其他物件從f-reachable狀態重新回到reachable狀態(L, M, N)
5. 處於finalizable狀態的物件不能同時是unreachable的,由第4點可知,將物件finalizable物件標記為finalized時會由某個執行緒執行該物件的finalize方法,致使其變成reachable。這也是圖中只有八個狀態點的原因
6. 程式設計師手動呼叫finalize方法並不會影響到上述內部標記的變化,因此JVM只會至多呼叫finalize一次,即使該物件“復活”也是如此。程式設計師手動呼叫多少次不影響JVM的行為
7. 若JVM檢測到finalized狀態的物件變成unreachable,回收其記憶體(I)
8. 若物件並未覆蓋finalize方法,JVM會進行優化,直接回收物件(O)
9. 注:System.runFinalizersOnExit()等方法可以使物件即使處於reachable狀態,JVM仍對其執行finalize方法
4. 一些程式碼示例
物件復活
public class GC {
public static GC SAVE_HOOK = null;
public static void main(String[] args) throws InterruptedException {
SAVE_HOOK = new GC();
SAVE_HOOK = null;
System.gc();
Thread.sleep(500);
if (null != SAVE_HOOK) { //此時物件應該處於(reachable, finalized)狀態
System.out.println("Yes , I am still alive");
} else {
System.out.println("No , I am dead");
}
SAVE_HOOK = null;
System.gc();
Thread.sleep(500);
if (null != SAVE_HOOK) {
System.out.println("Yes , I am still alive");
} else {
System.out.println("No , I am dead");
}
}
protected void finalize() throws Throwable {
super.finalize();
System.out.println("execute method finalize()");
SAVE_HOOK = this;
}
}
覆蓋finalize方法以確保資源釋放
作為一個補充操作,以防使用者忘記“關閉“資源,JDK中FileInputStream、FileOutputStream、Connection類均用了此”技術“,下面程式碼摘自FileInputStream類
/**
* Ensures that the <code>close</code> method of this file input stream is
* called when there are no more references to it.
*
* @exception IOException if an I/O error occurs.
* @see java.io.FileInputStream#close()
*/
protected void finalize() throws IOException {
if ((fd != null) && (fd != FileDescriptor.in)) {
/*
* Finalizer should not release the FileDescriptor if another
* stream is still using it. If the user directly invokes
* close() then the FileDescriptor is also released.
*/
runningFinalize.set(Boolean.TRUE);
try {
close();
} finally {
runningFinalize.set(Boolean.FALSE);
}
}
}