垃圾收集器如何判定對象可被回收

概述

我們一直講Java的垃圾回收算法,有標記-清除、複製算法、標記-整理、分代收集算法,但是怎麼判斷一個對象是否應該被回收呢?通過什麼去判定?標記是要標記哪些?接下來我們一起來分析。

對象死了嗎

在堆裏面存放着Java世界中幾乎所有的對象實例,垃圾收集器在對堆進行回收前,第一件事情就是要確定這些對象之中哪些還活着,哪些已經死了(不再被任何途徑使用的對象)。

引用計數算法

書面解釋:給對象添加一個引用計數器,每當有一個地方引用他時,計數器值加1,當引用失效時,計數器值就減1,任何時候計數器爲0的對象就是不可能再被使用的。
但是虛擬機並不是通過引用計數器算法來判定對象是否存活的。

可達性分析算法

在主流的程序語言的主流實現中,都是通過可達性分析來判定對象是否存活的。這個算法的基本思路就是通過一系列的稱爲“GC Roots”的對象爲起始點,從這些節點開始向下搜索,搜索所走過的路徑稱爲引用鏈,當一個對象到GC Roots沒有任何引用鏈相連相連時(就是從GC Root到這個對象不可達),則證明此對象是不可用的。
在這裏插入圖片描述
在Java語言中,可作爲GC Roots的科大對象包括下面幾種:

  • 虛擬機棧(棧幀中的本地變量表)中引用的對象。
  • 方法區中的類靜態屬性引用的對象。
  • 方法區中常量引用的對象。
  • 本地方法棧中JNI(即一般說的Native方法)引用的對象。

再談引用

無論是通過引用計數算法判斷對象的引用數量,還是通過可達性分析算法判斷對象的引用鏈是否可達,判定對象是否存活都與引用有關。
引用的定義:如果reference類型的數據中存儲的數值代表的是另外一塊內存的起始地址,就稱這塊內存代表着一個引用。這種定義很純粹,只有是與否。
在java1.2之後,Java對引用的概念做了擴充,將引用分爲強引用、軟引用、弱引用、虛引用4種,這4種引用強度依次逐漸減弱。

  • 強引用就是指在程序代碼志宏普遍存在的。類似Object obj = new Object()這類的引用,只要強引用還存在,垃圾收集器永遠不會回收掉被引用的對象。
  • 軟引用是用來描述一些還有用但並非必需的對象。對於軟引用關聯着的對象,在系統將要發生內存溢出異常之前,將會把這些對象列進回收範圍之中進行第二次回收。如果這次回收還是沒有足夠的內存,詞啊會拋出內存溢出異常。SoftReference來實現軟引用。
  • 弱引用也是用來描述非必需對象的,但是他的強度比軟引用更弱一些,被弱引用關聯的對象只能生存到下一次垃圾收集發生之前。當垃圾收集器工作時,無論當前內存是否足夠,都會回收掉被弱引用關聯的對象。WeakReference來實現弱引用。
  • 虛引用也稱幽靈引用或者幻影引用,他是最弱的一種引用關係。一個對象是否有虛引用的存在,完全不會對其生存時間構成影響,也無法通過虛引用來取得一個對象實例。爲一個對象設置虛引用關聯的唯一目的就是能在這個對象被收集器回收時收到一個系統通知。PhantomReference來實現虛引用。

生存還是死亡?

即使在可達性分析算法中不可達的對象,也並非是非死不可的,這時候他們暫時處於緩刑階段,要真正宣告一個對象死亡,至少要經歷兩次標記過程:如果對象在進行可達性分析後發現沒有與GC Roots相連接的引用鏈,那他江北第一次標記並且進行一次篩選,篩選的條件時此對象是否有必要執行finalize方法。當對象沒有覆蓋finalize方法,或者該方法已經被虛擬機調用過,虛擬機將這兩種情況都視爲沒有必要執行。
如果這個對象被判定爲有必要執行finalize方法,那麼這個對選哪個將會放置在一個叫做F-Queue的隊列中,並在稍後由一個虛擬機自動建立的、低優先級的Finalizer線程去執行它。這裏所說的執行,只是會觸發這個方法,並不保證執行完,因爲如果一個對象的finalize方法中執行很慢,或者發生了死循環,加你個很可能會導致F-Queue隊列中其他對象永久處於等待,甚至導致整個內存回收系統奔潰。finalize方法是對象逃脫死亡命運的最後一次機會,稍後GC將對F-Queue中的對象進行第二次標記,如果對象要在finalize中拯救自己,只要重新與引用連上的任何一個對象建立關聯即可,譬如把自己(this)賦值給某個類的變量或者對象的成員變量,那在第二次標記時就會把它移除“即將回收”集合,如果對象這時還沒有逃脫,那基本上他就真的被回收了。
下面是一次對象的自我拯救的演示

/**
*此代碼演示了兩點:
*1.對象可以在被GC時自我拯救。 *2.這種自救的機會只有一次,因爲一個對象的finalize()方法最多隻會被系統自動調用一次 *@author zzm
*/
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{
		super.finalize();
		System.out.println("finalize mehtod executed!"); 	
		FinalizeEscapeGC.SAVE_HOOK = this;
	}
	public static void main(String[]args) throws Throwable { 
		SAVE_HOOK = new FinalizeEscapeGC();
		//對象第一次成功拯救自己
		SAVE_HOOK = null;
		System.gc();
		//因爲finalize方法優先級很低,所以暫停0.5秒以等待它
		Thread.sleep(500);
		if(SAVE_HOOK != null) {
			SAVE_HOOK.isAlive();
		} else {
			System.out.println("no,i am dead:(");
		}
		//下面這段代碼與上面的完全相同,但是這次自救卻失敗了
		SAVE_HOOK = null;
		System.gc();
		//因爲finalize方法優先級很低,所以暫停0.5秒以等待它
		Thread.sleep(500);
		if(SAVE_HOOK != null) {
			SAVE_HOOK.isAlive();
		} else {
			System.out.println("no,i am dead:(");
		}
	}
}

值得注意的地方是,代碼中有兩段完全一樣的代碼片段,執行結果卻是一次逃 脫成功,一次失敗,這是因爲任何一個對象的finalize()方法都只會被系統自動調用一次, 如果對象面臨下一次回收,它的finalize()方法不會被再次執行,因此第二段代碼的自救行 動失敗了。

回收方法區

很多人認爲方法區是沒有垃圾收集器的,Java虛擬機規範中確實說過可以不要子啊方法區實現垃圾手機,而且方法區中進行垃圾收集的性價比一般比較低,在堆中,尤其是在新生代中,常規應用進行一次垃圾手機一般可以回收75%~95%的空間,而永久代的來及手機效率遠低於此。
永久代的垃圾收集主要回收兩部分內容:廢棄常量和無用的類。回收廢棄常量與回收Java堆中的對象非常類似。以常量池中字面量的回收爲例,例如一個字符串“abc”已經進入了常量池中,但是當前系統沒有任何一個String對象叫做“abc”的,換句話說,就是沒有任何String對象引用常量池中的“abc”常量,也沒有其他地方引用了這個字面量,如果這是發生內存回收,而且必要的話,這個“abc”常量就會被系統清理出常量池。常量池中的其他類(接口)、方法、字段的符號引用也與此類似。
pending一個常量是否是“廢棄常量”比較簡單,而要判定一個類是否是無用的類的條件則相對苛刻許多。類需要同時滿足下面3個條件纔算是無用的類:

  • 該類所有的實例都已經被回收,也就是Java堆中不存在該類的任何實例。
  • 架子啊該類的ClassLoader已經被回收。
  • 該類對應的java.lang.Class對象沒有再任何地方被引用,無法在任何地方通過反射訪問該類的方法。
    虛擬機可以對滿足上述3個條件的無用類進行回收,這裏說的僅僅是可以,而不是和對象一樣,不用了就必然會回收。是否對類進行回收,需要虛擬機支持。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章