java回收

對象可達性分析

這個算法通過一系列的稱爲“GC Roots“的對象作爲起點，從這些起點開始往下搜索，搜索到所走過的路徑稱爲引用鏈（Reference Chain）,當一個對象到GC Root沒有任何引用鏈時，則張光明此對象是不可用的。

途中object6，object7雖然互相有關聯，但是他們到GC roots是不可達的，所以他們被判定爲可回收的對象。

在Java語言中，可作爲GC Roots對象包括下面幾種：

虛擬機棧（棧幀中的本地變量表）中引用的對象。

方法區中類靜態屬性引用的對象。

方法區中常量引用的對象。

本地方法棧中JNI（即一般說的Native方法）引用的對象。

再談引用

JDK1.2以前，Java中的引用的定義很傳統：如果reference類型的數據中存儲的數據代表的是另外一塊內存的起始地址，就稱這塊內存代表着一個引用。我們希望描述這樣一類對象：當內存空間還足夠時，則能保留在內存之中；如果內存空間在進行垃圾收集後還是很緊張，則可以拋棄這些對象。

JDk1.2之後，Java對引用的概念進行了擴充，將引用分爲強引用（Strong Reference）、軟應用（Soft Reference）、弱引用（Weak Reference）、虛引用（Phantom Reference）4種，這四種引用強度依次逐漸減弱。

強引用就是指在程序代碼中普遍存在的，類似“Object obj = new Object（）”這類的引用，只要強引用還存在，來及收集器永遠不會回收掉被引用的對象。

軟引用是用來描述一些還有用但是並非必需的對象。對於軟引用關聯着的對象，在系統將要發生內存溢出異常之前，將會把這些對象列進回收範圍之中進行第二次回收。如果這次回收還沒有足夠的內存，纔會拋出內存溢出異常。

弱引用也是用來描述非必需對象的，但是它的強度比軟引用更弱一些，被軟引用關聯的對象只能生存到下一次垃圾收集器發生之前。當垃圾收集器工作時，無論當前內存是都足夠，都會回收掉只被弱引用關聯的對象。

虛引用也稱幽靈引用或者幻影引用，他是最弱的一種引用關係。一個對象是否有虛引用的存在，完全不會對其生存時間構成影響，也無法通過虛引用來獲取一個對象的實例。爲一個對象設置虛引用關聯的唯一目的就是能在這個對象被收集器回收時收到一個通知。

生存還是死亡

即使在可達性分析算法中的不可達對象，也並非是“非死不可”的，這時候它們暫時處於“緩刑”階段，要真正宣告一個對象死亡，至少要經歷兩次標記過程：如果對象在進行可達性分析後發現沒有與GC Roots項鍊接的引用鏈，那它會被第一次標記並且進行一次篩選，篩選的條件是此對象是否有必要執行finalize（）方法。當對象沒有覆蓋finalize（）方法，或者finalize（）方法已經被虛擬機調用過，虛擬機將這兩種情況都視爲“沒有必要執行”。

如果這個對象被判定爲必要執行finalize（）方法，那麼這個對象將會放置在一個叫做F-Queue的隊列之中，並在稍後由一個由虛擬機自動建立的、低優先級的Finalizer線程區執行它。這裏所謂的“執行”是指虛擬機會觸發這個方法，但並不保證會等待它執行借宿。finalize（）方法是對象逃脫死亡命運的最後一次機會，稍後GC將對F-Queue中的對象進行過第二次小規模的標記，如果對象要在finalize（）中成功拯救自己——只要重新與引用鏈上的任何一個對象建立關聯即可。

package org.think.java.jvm;

public class FinalizeEscapeGC {
	public static FinalizeEscapeGC SAVE_HOOK= null;
	public void isAlive(){
		System.out.println("yes,i am still alive:");
	}
	@Override
	protected void finalize() throws Throwable {
		// TODO Auto-generated method stub
		super.finalize();
		System.out.println("finalize method excuted！");
		FinalizeEscapeGC.SAVE_HOOK = this;
	}
	public static void main(String[] args) throws InterruptedException {
		SAVE_HOOK = new FinalizeEscapeGC();
		//第一次拯救自己
		SAVE_HOOK = null;
		System.gc();
		Thread.sleep(500);//因爲finalize方法優先級很低，所以暫停0.5s等待它
		if(SAVE_HOOK!=null){
			SAVE_HOOK.isAlive();
		}else{
			System.out.println("no,i am dead:");
		}
		//下面的這段代碼與上面的完全相同，但是這次自救卻失敗了
		SAVE_HOOK = null;
		System.gc();
		Thread.sleep(500);
		if(SAVE_HOOK!=null){
			SAVE_HOOK.isAlive();
		}else{
			System.out.println("no,i am dead:");
		}
	}
}

運行結果

finalize method excuted！
yes,i am still alive:
no,i am dead:

任何一個對象的finalize（）方法都只能被系統自動調用一次，如果對象面臨下一次回收，它的finalize（）方法不會被再次執行。

回收方法區

java虛擬機規範中明確說過可以不要求虛擬機在方法區實現垃圾收集，而且在方法區中進行來積極收集的“性價比一般比較低：在對中，尤其是在新生代中，常規應用進行一次來及收集一般啊可以回收70%~95%的空間，而永久代放入垃圾收集率遠低於此。

永久代垃圾收集主要回收兩部分內容：廢棄常量和無用類。回收廢棄常量和回收java堆中的對象非常類似。

判定一個類是否是“無用類”的條件相對比較苛刻。類需要同時滿足下面3個條件纔算是“無用類”:

該類所有的實例都已經被回收，也就是Java堆中不存在該類的任何實例。

加載該類的ClassLoader已經被回收。

該類對應的java.lang.Class對象沒有任何地方被引用，無論在任何地方通過反射訪問該類的方法

虛擬機可以對滿足上述3個條件的無用類進行回收，這裏說的僅僅是“可以”，而不是和對象一樣，不使用了就必然會回收。是否對類進行回收，HotSpot虛擬機提供了-Xnoclassgc參數進行控制，還可以使用-verbose:class以及-XX：+TraceClassLoading、-XX：+TraceClassUnloading查看類加載和卸載的信息，其中-verbose:class以及-XX：+TraceClassLoading可以在Product版的虛擬機中使用，-XX：+TraceClassUnloading參數需要FastDebug版的虛擬機支持。

在大量使用反射、動態代理、CGLib等ByteCode框架、動態生成Jsp及OSGI這類頻繁自定義ClassLoader的場景都需要虛擬機具備類卸載功能，以保證永久代不會溢出。