垃圾回收器要回收對象的時候，首先要調用這個類的finalize方法(你可以 寫程序驗證這個結論)，一般的純Java編寫的Class不需要重新覆蓋這個方法，因為Object已經實現了一個默認的，除非我們要實現特殊的功能(這 里面涉及到很多東西，比如對象空間樹等內容)。
不過用Java以外的代碼編寫的Class(比如JNI，C++的new方法分配的內存)，垃圾回收器并不能對這些部分進行正確的回收，這時就需要我們覆蓋默認的方法來實現對這部分內存的正確釋放和回收(比如C++需要delete)。
總之，finalize相當于析構函數，他是垃圾回收器回收一個對象的時候第一個要調用的方法。不過由于Java的垃圾回收機制能自動為我們做這些事情，所以我們在一般情況下是不需要自己來手工釋放的。

有時當撤消一個對象時，需要完成一些操作。例如，如果一個對象正在處理的是非Java 資源，如文件句柄或window 字符字體，這時你要確認在一個對象被撤消以前要保證這些資源被釋放。為處理這樣的狀況，Java 提供了被稱為收尾（finalization ）的機制。使用該機制你可以定義一些特殊的操作，這些操作在一個對象將要被垃圾回收程序釋放時執行。
要給一個類增加收尾（finalizer ），你只要定義finalize ( ) 方法即可。Java 回收該類的一個對象時，就會調用這個方法。在finalize ( )方法中，你要指定在一個對象被撤消前必須執行的操作。垃圾回收周期性地運行，檢查對象不再被運行狀態引用或間接地通過其他對象引用。就在對象被釋放之 前，Java 運行系統調用該對象的finalize( ) 方法。

　　finalize()方法的通用格式如下：

　　其中，關鍵字protected是防止在該類之外定義的代碼訪問finalize()標識符。該標識符和其他標識符將在第7章中解釋。

　　理解finalize( ) 正好在垃圾回收以前被調用非常重要。例如當一個對象超出了它的作用域時，finalize( ) 并不被調用。這意味著你不可能知道何時——甚至是否——finalize( ) 被調用。因此，你的程序應該提供其他的方法來釋放由對象使用的系統資源，而不能依靠finalize( ) 來完成程序的正常操作。

　　注意：如果你熟悉C++，那你知道C++允許你為一個類定義一個撤消函數（destructor ），它在對象正好出作用域之前被調用。Java不支持這個想法也不提供撤消函數。finalize() 方法只和撤消函數的功能接近。當你對Java 有豐富經驗時，你將看到因為Java使用垃圾回收子系統，幾乎沒有必要使用撤消函數。

finalize的工作原理應該是這樣的：一旦垃圾收集器準備好釋放對象占用的存儲空間，它首先調用finalize()，而且只有在下一次垃圾收集過程中，才會真正回收對象的內存.所以如果使用finalize()，就可以在垃圾收集期間進行一些重要的清除或清掃工作.

finalize()在什么時候被調用?
有三種情況

1. 所有對象被Garbage Collection時自動調用,比如運行System.gc()的時候.
2. 程序退出時為每個對象調用一次finalize方法。
3. 顯式的調用finalize方法

除此以外,正常情況下,當某個對象被系統收集為無用信息的時候,finalize()將被自動調用,但是jvm不保證finalize()一定被調用,也就是說,finalize()的調用是不確定的,這也就是為什么sun不提倡使用finalize()的原因

有時當撤消一個對象時，需要完成一些操作。例如，如果一個對象正在處理的是非Java 資源，如文件句柄或window 字符字體，這時你要確認在一個對象被撤消以前要保證這些資源被釋放。為處理這樣的狀況，Java 提供了被稱為收尾（finalization ）的機制。使用該機制你可以定義一些特殊的操作，這些操作在一個對象將要被垃圾回收程序釋放時執行。

要給一個類增加收尾（finalizer ），你只要定義finalize ( ) 方法即可。Java 回收該類的一個對象時，就會調用這個方法。在finalize ( )方法中，你要指定在一個對象被撤消前必須執行的操作。垃圾回收周期性地運行，檢查對象不再被運行狀態引用或間接地通過其他對象引用。就在對象被釋放之 前，Java 運行系統調用該對象的finalize( ) 方法。

finalize()方法的通用格式如下：

其中，關鍵字protected是防止在該類之外定義的代碼訪問finalize()標識符。該標識符和其他標識符將在第7章中解釋。

理解finalize( ) 正好在垃圾回收以前被調用非常重要。例如當一個對象超出了它的作用域時，finalize( ) 并不被調用。這意味著你不可能知道何時——甚至是否——finalize( ) 被調用。因此，你的程序應該提供其他的方法來釋放由對象使用的系統資源，而不能依靠finalize( ) 來完成程序的正常操作。

注意：如果你熟悉C++，那你知道C++允許你為一個類定義一個撤消函數（destructor ），它在對象正好出作用域之前被調用。Java不支持這個想法也不提供撤消函數。finalize() 方法只和撤消函數的功能接近。當你對Java 有豐富經驗時，你將看到因為Java使用垃圾回收子系統，幾乎沒有必要使用撤消函數。

垃圾收集器在進行垃圾收集的時候會自動呼叫對象的finalize方法，用來進行一些用戶自定義的非內存清理工作，因為垃圾收集器不會處理內存以外的東西。所以，有的時候用戶需要定義一些清理的方法，比如說處理文件和端口之類的非內存資源。

1.JVM的gc概述
　　
　　gc即垃圾收集機制是指jvm用于釋放那些不再使用的對象所占用的內存。java語言并不要求jvm有gc，也沒有規定gc如何工作。不過常用的jvm都有gc，而且大多數gc都使用類似的算法管理內存和執行收集操作。
　　
　　在充分理解了垃圾收集算法和執行過程后，才能有效的優化它的性能。有些垃圾收集專用于特殊的應用程序。比如，實時應用程序主要是為了避免垃圾收集中斷，而大多數OLTP應用程序則注重整體效率。理解了應用程序的工作負荷和jvm支持的垃圾收集算法，便可以進行優化配置垃圾收集器。
　　
　　垃圾收集的目的在于清除不再使用的對象。gc通過確定對象是否被活動對象引用來確定是否收集該對象。gc首先要判斷該對象是否是時候可以收集。兩種常用的方法是引用計數和對象引用遍歷。
　　
　　1.1.引用計數
　　
　　引用計數存儲對特定對象的所有引用數，也就是說，當應用程序創建引用以及引用超出范圍時，jvm必須適當增減引用數。當某對象的引用數為0時，便可以進行垃圾收集。
　　
　　1.2.對象引用遍歷
　　
　　早期的jvm使用引用計數，現在大多數jvm采用對象引用遍歷。對象引用遍歷從一組對象開始，沿著整個對象圖上的每條鏈接，遞歸確定可到達（reachable）的對象。如果某對象不能從這些根對象的一個（至少一個）到達，則將它作為垃圾收集。在對象遍歷階段，gc必須記住哪些對象可以到達，以便刪除不可到達的對象，這稱為標記（marking）對象。
　　
　　下一步，gc要刪除不可到達的對象。刪除時，有些gc只是簡單的掃描堆棧，刪除未標記的未標記的對象，并釋放它們的內存以生成新的對象，這叫做清除（sweeping）。這種方法的問題在于內存會分成好多小段，而它們不足以用于新的對象，但是組合起來卻很大。因此，許多gc可以重新組織內存中的對象，并進行壓縮（compact），形成可利用的空間。
　　
　　為此，gc需要停止其他的活動活動。這種方法意味著所有與應用程序相關的工作停止，只有gc運行。結果，在響應期間增減了許多混雜請求。另外，更復雜的gc不斷增加或同時運行以減少或者清除應用程序的中斷。有的gc使用單線程完成這項工作，有的則采用多線程以增加效率。
　　
2.幾種垃圾回收機制
　　
　　2.1.標記－清除收集器
　　
　　這種收集器首先遍歷對象圖并標記可到達的對象，然后掃描堆棧以尋找未標記對象并釋放它們的內存。這種收集器一般使用單線程工作并停止其他操作。
　　
　　2.2.標記－壓縮收集器
　　
　　有時也叫標記－清除－壓縮收集器，與標記－清除收集器有相同的標記階段。在第二階段，則把標記對象復制到堆棧的新域中以便壓縮堆棧。這種收集器也停止其他操作。
　　
　　2.3.復制收集器
　　
　　這種收集器將堆棧分為兩個域，常稱為半空間。每次僅使用一半的空間，jvm生成的新對象則放在另一半空間中。gc運行時，它把可到達對象復制到另一半空間，從而壓縮了堆棧。這種方法適用于短生存期的對象，持續復制長生存期的對象則導致效率降低。
　　
　　2.4.增量收集器
　　
　　增量收集器把堆棧分為多個域，每次僅從一個域收集垃圾。這會造成較小的應用程序中斷。
　　
　　2.5.分代收集器
　　
　　這種收集器把堆棧分為兩個或多個域，用以存放不同壽命的對象。jvm生成的新對象一般放在其中的某個域中。過一段時間，繼續存在的對象將獲得使用期并轉入更長壽命的域中。分代收集器對不同的域使用不同的算法以優化性能。
　　
　　2.6.并發收集器
　　
　　并發收集器與應用程序同時運行。這些收集器在某點上（比如壓縮時）一般都不得不停止其他操作以完成特定的任務，但是因為其他應用程序可進行其他的后臺操作，所以中斷其他處理的實際時間大大降低。
　　
　　2.7.并行收集器
　　
　　并行收集器使用某種傳統的算法并使用多線程并行的執行它們的工作。在多cpu機器上使用多線程技術可以顯著的提高java應用程序的可擴展性。

3.對象的銷毀過程

在對象的銷毀過程中，按照對象的finalize的執行情況，可以分為以下幾種，系統會記錄對象的對應狀態：
unfinalized 沒有執行finalize，系統也不準備執行。
finalizable 可以執行finalize了，系統會在隨后的某個時間執行finalize。
finalized 該對象的finalize已經被執行了。

GC怎么來保持對finalizable的對象的追蹤呢。GC有一個Queue，叫做F-Queue，所有對象在變為finalizable的時候會加入到該Queue，然后等待GC執行它的finalize方法。

這時我們引入了對對象的另外一種記錄分類，系統可以檢查到一個對象屬于哪一種。
reachable 從活動的對象引用鏈可以到達的對象。包括所有線程當前棧的局部變量，所有的靜態變量等等。
finalizer-reachable 除了reachable外，從F-Queue可以通過引用到達的對象。
unreachable 其它的對象。

來看看對象的狀態轉換圖。

好大，好暈，慢慢看。

1 首先，所有的對象都是從Reachable+Unfinalized走向死亡之路的。

2 當從當前活動集到對象不可達時，對象可以從Reachable狀態變到F-Reachable或者Unreachable狀態。

3 當對象為非Reachable+Unfinalized時，GC會把它移入F-Queue，狀態變為F-Reachable+Finalizable。

4 好了，關鍵的來了，任何時候，GC都可以從F-Queue中拿到一個Finalizable的對象，標記它為Finalized，然后執行它的finalize方法，由于該對象在這個線程中又可達了，于是該對象變成Reachable了（并且Finalized）。而finalize方法執行時，又有可能把其它的F-Reachable的對象變為一個Reachable的，這個叫做對象再生。

5 當一個對象在Unreachable+Unfinalized時，如果該對象使用的是默認的Object的finalize，或者雖然重寫了，但是新的實現什么也不干。為了性能，GC可以把該對象之間變到Reclaimed狀態直接銷毀，而不用加入到F-Queue等待GC做進一步處理。

6 從狀態圖看出，不管怎么折騰，任意一個對象的finalize只至多執行一次，一旦對象變為Finalized，就怎么也不會在回到F-Queue去了。當然沒有機會再執行finalize了。

7 當對象處于Unreachable+Finalized時，該對象離真正的死亡不遠了。GC可以安全的回收該對象的內存了。進入Reclaimed。

對象重生的例子

期待輸出

但是有可能失敗，源于GC的不確定性以及時序問題，多跑幾次應該可以有成功的。詳細解釋見文末的參考文檔。

    3.1對象的finalize的執行順序

所有finalizable的對象的finalize的執行是不確定的，既不確定由哪個線程執行，也不確定執行的順序。
考慮以下情況就明白為什么了，實例a,b,c是一組相互循環引用的finalizable對象。

    3.2何時及如何使用finalize

從以上的分析得出，以下結論。
（1） 最重要的，盡量不要用finalize，太復雜了，還是讓系統照管比較好。可以定義其它的方法來釋放非內存資源。
（2） 如果用，盡量簡單。
（3） 如果用，避免對象再生，這個是自己給自己找麻煩。
（4） 可以用來保護非內存資源被釋放。即使我們定義了其它的方法來釋放非內存資源，但是其它人未必會調用該方法來釋放。在finalize里面可以檢查一下，如果沒有釋放就釋放好了，晚釋放總比不釋放好。
（5） 即使對象的finalize已經運行了，不能保證該對象被銷毀。要實現一些保證對象徹底被銷毀時的動作，只能依賴于java.lang.ref里面的類和GC交互了。