三 垃圾收集器和記憶體分配策略

3.1 垃圾收集(Garbage Collection,GC)和記憶體動態分配最早於1960年的MIT開發的Lisp語言中使用

需要解決的三個問題：

• 回收哪些記憶體
• 什麼時候回收
• 怎麼回收

程式計數器，虛擬機器棧，本地方法棧3個區域隨執行緒生死，棧中的每個棧幀分配多少記憶體已經在類結構確定的時候已知，因此這幾個區域的記憶體分配和回收都具確定性

而java堆和方法區則不同，同一個介面的不同實現類的記憶體可能不一樣，我們只有在執行期才能知道建立哪些物件，當然這些物件的記憶體空間分配和回收也是動態的，垃圾收集器關注的是這部分記憶體

儘管目前記憶體動態分配和垃圾回收已經非常成熟在技術方面，但是因為需要排除各種記憶體溢位，記憶體洩漏問題，同時系統需要更高併發量而垃圾收集是提高這個併發量手段時候，我們需要對這個自動化的記憶體分配和記憶體回收進行監控調節優化

3.2 物件是否存活的判斷演算法

堆中存放著java中所有的物件例項，垃圾收集器回收堆中物件的時候，必須判斷物件是否還存活，即物件是否可達。

判斷物件是否存活的演算法有以下兩種

• 引用計數器演算法：道理很簡單，給物件裡面新增一個引用計數器，物件被引用一次，計數器+1，引用失效一次，計數器-1，當計數器為0的時候說明物件是不可能被使用的，著名的Python語言就使用的該演算法。但是很可惜，java虛擬機器並沒有使用該演算法管理記憶體，最主要原因：難以解決物件之間相互引用所造成的問題
• 可達性分析演算法 reachability analysis 通過一系列GC Roots的物件作為起始點，然後向下搜尋，搜尋走過的路徑叫做引用鏈，當物件和GC root's沒有任何引用鏈條相連的話，該物件即不可用，儘管下圖中物件5，6，7互相關聯，但是和根節點GC Roots沒有連線，即不可達，所有5，6，7節點是判定可回收物件

java中，可作為GC Roots的物件有

• 虛擬機器棧引用的物件
• 方法區中類靜態成員引用的物件
• 方法區中常量引用的物件
• 本地方法棧中引用的物件

物件的引用分4種

• 強引用：類似Object o = new Object()；只要強引用存在，垃圾收集器永遠不回收被引用物件
• 軟引用：描述還有用但是非必須的物件，如果系統將要記憶體溢位，則在第二次垃圾回收的時候回收這些物件，當回收以後還沒足夠記憶體，就丟擲記憶體溢位exception
• 弱引用：比軟引用強度更低，只要收集器開始工作，在第二次垃圾回收之前就會將被弱引用關聯的物件回收
• 虛引用：最弱的引用關係，一個物件的生存時間和是否具有虛引用無關，即虛引用不存在了，物件仍然可能存在，當然，也無法通過虛引用取得一個物件例項，為物件設定虛引用關聯的唯一目的就是該物件在被回收的時候可以收到一個系統通知

3.3 可達性分析演算法種不可達的物件是否一定死亡？

不一定，當發現某個物件不可達的時候，會對他進行第一次標記，看是否執行finalize方法，當物件沒有覆蓋finalize方法或者finalize方法已經被vm呼叫，則沒必要執行

如果執行，那麼他會被加入F-queue佇列，然後啟動一個後臺執行緒去執行他，不保證會執行完，加入佇列以後過一會將會進行第二次標記，如果物件在finalize中成功拯救了自己，即將this賦值給某個成員變數，則第二次標記的時候將會把他移出即將回收的集合，如果沒有逃脫，那麼這個物件就真的被回收了，程式碼如下

public class JVMt {

	static JVMt jvmt = null;
	
	@Override
	protected void finalize() throws Throwable {
		super.finalize();
		System.out.println("enter finalize method");
		JVMt.jvmt = this;
	}

	public static void main(String[] args) throws InterruptedException {
		jvmt = new JVMt();
		
		// 讓它不可達
		jvmt = null;
		
		// 啟動GC
		System.gc();
		
		// finalize優先順序低，需要等待時間讓他執行
		Thread.sleep(500);
		
		if(jvmt!=null) {
			System.out.println("I am stil alive");
		}else {
			System.out.println("I am dead");
		}
		
		// 讓它不可達
		jvmt = null;
		
		// 啟動GC
		System.gc();
		
		// finalize優先順序低，需要等待時間讓他執行
		Thread.sleep(500);
				
		if(jvmt!=null) {
			System.out.println("I am stil alive");
		}else {
			System.out.println("I am dead");
		}
	}
	
}

結果：

enter finalize method
I am stil alive
I am dead

3.4 GC對於方法區的回收

主要兩部分

• 廢棄常量的回收：比如abc，常量池中沒有任何一個String物件是abc

• 類的回收：需要滿足3個條件

  1. java堆中該類的例項已經被完全回收完

  2. 該類的類載入器已經被回收

  3. 該類的 Class物件沒有引用，無法在任何地方通過反射訪問該類

3.5 垃圾收集演算法

• 標記清理演算法Mark-sweep：最基本的演算法，標記需要回收的物件，然後標記完成後對這些物件進行統一回收，有兩個缺點：

  1. 效率不高：標記的過程和清理的過程效率都不高

  2. 容易產生大量不連續的記憶體碎片，如果碎片太多，以後如果要分配較大物件的時候，使得無法找到足夠大的連續記憶體而提前觸發下一次GC

• 複製演算法Copying：目前商用虛擬機器對於新生代收集最流行演算法，原理是將堆中可用記憶體按照容量大小平均的1：1劃分為2部分，每次只使用1部分，使用的這一部分中物件可分為3個組成塊（可以回收，存活物件，空閒記憶體），當這一部分中的所有記憶體用完以後，即可以回收+存活物件所佔記憶體=區間記憶體------------>就將這塊還存活的物件複製到另一部分中，然後堆這部分中的可以回收進行GC

  優點：高效：只需移動指標，不需考慮記憶體碎片化等複雜情況

  確定：浪費記憶體，每次只是用一部分記憶體

  HotSpot虛擬機器使用的GC演算法就是這個，將堆分為3部分，Eden，from survivor，to survivor,三者的比例是8:1:1，其中Eden和from survivor主要用於存放物件，回收的時候就將這兩塊的物件一次性複製到to survivor記憶體中，如果to survivor空間容量不足以存放上一次新生代收集的存活物件的時候，這些物件直接通過分配擔保機制進入老年代

• 標記整理演算法：考慮到複製演算法，如果存活的物件數量龐大，在記憶體滿以後進行復制效率無疑下降太多，同時如果不想浪費剩下的50%記憶體，就需要額外空間分配擔保，以避免存活物件100%的極端情況，因此在老年代一般不用這種

  老年代選用標記整理演算法，和標記清理演算法很類似，就是所有物件標記完成以後先不清理，而是先將存活物件移動到邊界整理，然後直接清理邊界以外的記憶體

• 分代收集演算法Generational Collection：當前商業虛擬機器最流行演算法，根據物件的存活 週期不同分為新生代和老年代，新生代每次都有大量物件死亡，少量存活，採用複製演算法，老年代因為物件存活率高，沒有額外空間使用標記整理/標記清除演算法