標記-清除算法
此垃圾收集算法分為“標記”和“清除”兩個階段：
首先標記出所有需要回收的對象，在標記完成后統一回收所有被標記對象，它的標記過程前面已經說過——如何判斷對象是否存活/死去
死去的對象就會被標記，然后被清除。
它主要有兩點不足：
一個是效率問題，標記和清除兩個過程的效率都不高；
另一個是空間問題，標記清除之后會產生大量不連續的空間碎片，空間碎片太多可能會導致以后再程序運行過程中需要分配較大對象時，
無法找到足夠的連續內存而不得不提前觸發另一次垃圾收集動作。
標記-清除算法的執行過程如下圖所示：
復制算法
復制算法的出現，解決了效率問題，它將可用內存按容量划分為大小相等的兩塊，每次只是用其中的一塊。當這一塊內存用完了，就將
還存活着的對象復制到另外一塊上面，然后再把已使用過的內存空間一次清理掉。這樣使得每次都是對整個半區進行內存回收，內存分配時
也就不用考慮內存碎片等復雜情況，只要一動堆頂指針，按順序分配內存即可，實現簡單，運行高效。
只是這種算法的代價是將內存縮小為了原來的一半，未免太高了點。
復制算法的執行過程如下圖：
現在的商業虛擬機都采用復制算法來回收新生代，IBM公司的專門研究表明，新生代中的對象98%是“朝生夕死”的，所以並不需要按照1:1的
比例來划分內存空間。
堆內存中的新生代分為一塊較大的Eden空間和兩塊較小的Survivor空間，詳情請看——JVM內存結構/JVM運行時數據區，以及堆內存的划分
每次使用Eden和其中一塊From Survivor，當回收時，將Eden和From Survivor中還存活着的對象一次性地復制到另外一塊To Survivor空間上，最
后清理掉Eden和剛才用過的From Survivor空間。
HotSpot虛擬機默認Eden：From Survivor：To Survivor = 8:1:1 ，也就是每次新生代中可用內存空間為整個新生代容量的90%（80%+10%），
只有10%的內存會被“浪費”。當然，98%的對象可回收只是一般場景下的數據，我們沒有辦法保證每次回收都只有不多於10%的對象存活，當To
Survivor空間不夠用時，需要依賴其它內存（這里指老年代）進行分配擔保（Handle Promotion）。
聽過某司的一個面試題，為什么新生代中Eden：From Survivor：To Survivor是8:1:1，就可以用上面的內容來解釋。
標記-整理算法
復制收集算法在對象存活率較高時就要進行較多的復制操作，效率將會變低。更關鍵的是，如果不想浪費50%的空間，就需要額外的空
間進行分配擔保，以應對被使用的內存中所有對象都100%存活的極端情況，所以老年代一般不能直接選用這種算法。
根據老年代的特點，有人提出了另外一種“標記-整理”（Mark-Compact）算法，標記過程仍然與“標記-清除”算法一樣，但后續步驟不是
直接對可回收對象進行清理，而是讓所有存活對象都向一端移動，然后直接清理掉端邊界以外的內存。
“標記-整理”算法的執行過程如下圖：
分代收集算法
當前商業虛擬機的垃圾收集都采用“分代收集”（Generational Collection）算法，這種算法並沒有什么新的思想，只是根據對象存活周
期的不同將內存划分為幾塊。一般是把Java堆分為新生代和老年代，這樣就可以根據各個年代的特點采用最合適的收集算法。在新生代中，
每次垃圾收集時都發現有大批對象死去，只有少量存活，那就選用復制算法，只需要付出少量存活對象的復制成本就可以完成收集。而老年
代中因為對象存活率高、沒有額外空間對它進行分配擔保，就必須使用“標記-整理”算法進行回收。