Java的垃圾收集演算法、垃圾收集器以及記憶體配置與回收策略

虛擬機器是如何判斷一個對象已經死去呢？大部分人都回答是引用計數演算法。
1. 引用計數演算法
給對象中添加一個引用計數器，每當有一個地方引用它時，計數器就加1；當引用失效時，計數器值就減1，任何時刻計數器值為0的對象就是不可能再被使用的。引用計數法的實現簡單，判定效率比較高，但是java中並沒有選擇引用計數法來管理記憶體，其中主要的原因是它很難解決對象之間的相互循環參考問題。objA.instance=objB;objB.instance=objA;除此之外，這兩個對象再無任何引用，實際上這兩個對象已經不可能再被訪問，但是它們相互引用，引用計數器無法通知GC收集器回收它們。

2. 根搜尋演算法
java c#以及Lisp都是使用根搜尋演算法判定對象是否存活的。這個演算法的基本思路就是通過一系列的名為GC Roots的對象作為起始點，從這些節點開始向下搜尋，搜尋所走過的路徑就稱為引用鏈。當一個對象到引用鏈沒有對象相連時，則證明此對象是停用。

對象的死亡曆程
當一個對象從GC Roots不可達以後，就可以被回收了，如果類覆蓋了finalize方法，就有可能會執行finalize，正常情況下執行完畢後，就面臨真正的記憶體回收，如果在finalize方法中，將對象本身賦值給另外一個變數，那就可以逃脫記憶體回收的命運，但是請注意，finalize方法只能調用一次，下一次這個對象再面臨記憶體回收的時候就不會再調用finalize方法了。

但是finalize方法中的工作不確定性太大，代價高昂，不鼓勵使用這個方法。

垃圾收集演算法

1. 標記-清除演算法
演算法分為標記和清除兩個階段：首先標記處所有需要回收的對象，在標記完成後統一回收掉所有被標記對象，是最基本的收集演算法。

2. 複製演算法
它將記憶體按容量劃分為大小相等的兩塊，每次只是用其中的一塊，當這一塊的記憶體用完了，就將還活著的對象複製到另外一塊上邊，然後把已經是用過的記憶體空間一次清理掉。這樣使得每次都是對其中的一塊進行記憶體回收，記憶體配置時也不用考慮記憶體片段等複雜情況，只要移動堆頂指標，按順序分配記憶體即可，實現簡單，高效。只是這種演算法的代價是將記憶體縮小為原來的一半。

3. 標記-整理演算法
標記過程仍然與“標記-整理演算法”一樣，但是後續步驟不是直接對可回收對象進行清理，而是讓所有存活對象都向一端移動，然後清理掉端邊界以外的記憶體。

4. 分代收集演算法
當前商業虛擬機器都採用這種演算法，根據對象的存活周期將記憶體劃分為幾塊，java堆分為新生代和老年代，這樣就可以根據各個年代的特點採用最適當的收集演算法。新生代中，每次垃圾收集都有大批對象死去，可以選用複製演算法，只需要付出少量存活對象的複製就可以完成收集。而老年代對象存活率高，沒有額外空間，必須使用標記-清理或者標記-整理演算法來進行回收。

垃圾收集器

在記憶體回收的語境中，有必要先解釋兩個名詞：並發和並行
並行：多條垃圾收集線程並行工作，但此時使用者線程仍然處於等待狀態
並發：使用者線程和垃圾收集線程同時工作，使用者程式繼續運行，而垃圾收集程式運行於另一個CPU上

1. Serial收集器  採用複製演算法
Serial收集器是最基本曆史最悠久的收集器，它是一個單線程的收集器，它在垃圾收集的時候必須暫停其他所有的背景工作執行緒，直到收集完成。垃圾收集的工作是由虛擬機器在後台自動發起和自動完成的，在使用者不可見的情況下把使用者的正常工作的線程全部停掉，這對很多應用來說都是難以接受的

但是它也有自己的優點：簡單高效 對於限定單個CPU的環境來說，收集器由於沒有線程互動的開銷，可以獲得最高的單線程收集效率。

2. ParNew收集器  採用複製演算法
ParNew收集器其實就是Serial收集器的多線程版本，包括收集器可用的控制參數、收集演算法、暫停所有使用者線程、對象分配策略、回收策略等都和Serial收集器完全一樣，它是運行在Server模式下的虛擬機器中首選的新生代收集器，其中一個原因是，除了Serial收集器，目前只有它能和CMS收集器配合使用。CMS收集器是HotSpot虛擬機器上第一款真正意義上的並發收集器

ParNew收集器在單CPU環境中不會比Serial收集器有更好的效果

3. Parallel Scavenge收集器 採用複製演算法
Paraller Scavenge收集器也是一個新生代收集器，使用複製演算法的收集器，是一個並行的多線程收集器

Parellel Scavenge收集器的特點是它的關注點和其它收集器不同，CMS等收集器儘可能的縮短垃圾收集時使用者線程的停頓時間，而Parallel Scavenge收集器的目標則是達到一個可控制的輸送量，輸送量是CPU用於運行使用者代碼的時間與CPU總消耗時間的比值。輸送量=運行使用者代碼時間/（運行使用者代碼時間+垃圾收集時間），虛擬機器運行了100分鐘，垃圾收集花掉1分鐘，輸送量是99%

停頓時間越短越適合與使用者互動的程式，良好的響應速度能提升使用者的體驗；高輸送量可以更高效的利用CPU時間

Parallel Scavenge收集器有一種稱為GC自適應調用策略，虛擬機器根據當前系統的運行情況收集效能監控資訊，動態調整參數以提供最合適的停頓時間或最大的輸送量

自適應策略也是Parallel Scavenge收集器與ParNew收集器的一個重要區別

4. Serial Old收集器 採用標記-整理演算法
它是Serial收集器的老年版本，單線程收集器，採用標記-整理演算法。

5. Parallel Old收集器 採用標記-整理演算法
Parallel Old是Parallel Scavenge收集器的老年版本，使用多線程和標記-整理演算法。

6. CMS收集器 採用標記-清理演算法
CMS收集器是一種以獲得最短回收停頓時間為目標的收集器。它分為四個步驟：初始標記、並發標記、重新標記、並發清除其中初始標記和重新標記兩個步驟任然需要暫停其它線程。

初始標記僅僅是標記一下GC Roots能直接關聯到的對象，速度很快，並發標記階段就是進行GC Roots Tracing的過程，而重新標記階段則是為了修正並發標記期間，因使用者程式繼續運作而導致標記產生變動的那一部分對象的標記記錄，這個階段一般比初始標記階段稍長一些，但遠比並發標記的時間短。

由於整個過程中耗時最長的並發標記和並發清理過程中，收集器都可以與使用者線程一起工作，所以總體上來說，CMS收集器的記憶體回收過程是與用於線程一起並發執行的。

CMS收集器的缺點：
CMS收集器對CPU資源非常敏感，面向並發設計的程式都對CPU資源比較敏感，雖然並發階段不會導致應用線程停頓，但是會因為佔用了一部分線程導致應用程式編碼，總輸送量會降低。

CMS是基於標記-清理演算法，收集結束的時候會產生大量空間片段，空間片段過多的時候將會給大家分配帶來很大的麻煩，玩玩會出現老年代有很大剩餘空間，但是無法找打足夠大的連續空間來分配當前對象，不得不提前觸發一次Full GC。

7. G1收集器 採用標記-整理演算法
G1收集器是收集器理論進一步發展的產物，它與CMS收集器相比有兩個重要的改進：G1收集器基於標記-整理演算法，不會產生空間片段，對於長時間啟動並執行應用程式來說非常重要。二是，它可以非常精確的控制停頓，能讓使用者明確指定一個長度為M毫秒的時間片段內，消耗在垃圾收集上的時間不得超過N毫秒

G1收集器可以實現在基本不犧牲輸送量的前提下完成低停頓的記憶體回收，它能夠避免全地區的垃圾收集。

記憶體配置與回收策略

Java技術體系中所提倡的自動記憶體管理最終可以歸結為自動化地解決了兩個問題：給對象分配記憶體以及回收分配給對象的記憶體。

對象的記憶體配置，就是在堆上分配，對象主要分配在新生代的Eden區上，少數情況下也可能會直接分配在老年代中

1. 對象優先在Eden分配
對象在新生代Eden區中分配，當Eden區沒有足夠的空間進行分配時，虛擬機器將發起一次Minor GC

2. 大對象直接進入老年代
所謂大對象就是指，需要大量連續記憶體空間的Java對象，最典型的就是那種很長的字串及數組

3. 長期存活的對象將進入老年代
虛擬機器給每個對象定義了一個對象年齡計數器，當年齡增加到一定程式時，就會被晉陞到老年代中

新生代使用複製收集演算法
Minor GC:發生在新生代的垃圾收集動作，Java對象大多都具有朝生夕滅的特性，所以Minor GC非常頻繁，一般回收速度也比較快

Major GC/Full GC:發生在老年代的GC，Major GC的速度一般會比Minor GC慢10倍以上。