本系列筆記主要基於《深入理解Java虛擬機：JVM高級特性與最佳實踐 第2版》，是這本書的讀書筆記。 垃圾收集演算法 垃圾收集演算法主要有標記 清除演算法、複製演算法、標記 整理演算法、分代收集演算法這幾種，對演算法的具體實現不做過多探究，只對他們的設計思想進行介紹。 標記 清除演算法 最基礎的演算法就是 標記 清除 ...
本系列筆記主要基於《深入理解Java虛擬機：JVM高級特性與最佳實踐 第2版》，是這本書的讀書筆記。
垃圾收集演算法
垃圾收集演算法主要有標記-清除演算法、複製演算法、標記-整理演算法、分代收集演算法這幾種，對演算法的具體實現不做過多探究，只對他們的設計思想進行介紹。
標記-清除演算法
最基礎的演算法就是標記-清除（Mark-Sweep）演算法，同它的名字一樣，分為“標記”和“清除”兩個階段：首先標記出所有待回收的對象，標記完後統一回收所有被標記的對象。標記過程其實就是上一篇文章講到的判斷對象是否“死亡”的過程，通過引用計數演算法或可達性分析演算法判斷對象是否需要回收。
標記-清除演算法是最基礎的演算法，因為其他演算法基本都是基於它進行改進發展而來。標記-清除演算法的不足主要有兩個：一個是效率問題，標記和清除兩個過程的效率都不高；另一個是空間問題，標記清楚後產生大量不連續的碎片空間，碎片空間太多會導致當需要分配大對象時，無法找到足夠大的連續空間而不得不提前觸發另一次垃圾收集。
標記-清除演算法的執行過程如下圖：
複製演算法
複製（Copying）演算法是為瞭解決”標記-清除“演算法的效率問題而生，它將記憶體劃分為容量大小相等的兩塊，每次只使用其中一塊，當這一塊記憶體使用完了，就將還存活的對象複製到另外一塊當中，然後把原來那一塊記憶體清空。這樣每次都是對整個半區進行記憶體回收，記憶體分配時也不用考慮空間碎片的情況，只要移動堆頂指針按順序分配即可，實現簡單，運行高效。只是這種演算法把記憶體縮小為原來的一半，代價高昂。
複製演算法的執行過程如下圖：
現代的很多商用虛擬機都是採用的這種收集演算法來回收新生代，有研究表明，新生代中的對象98%都是”朝生夕死“的，所以不需要按照1:1的比例來劃分記憶體空間，而是將記憶體分為一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden空間和其中一塊Survivor空間，當回收時，Eden和Survivor中還存活的對象一次性複製到另外一塊Survivor中，然後清理掉Eden空間和剛纔用過的Survivor空間。
HotSpot虛擬機劃分的Eden空間和Survivor空間的比例是8:1，也就是把新生代空間劃分為8:1:1的三部分，每次新生代中可以使用的記憶體為90%，被浪費的只有10%。
當然，98%的對象可回收只是一般場景下的數字，我們不能保證每次回收後只有不多於10%的對象存活，當Survivor空間不夠用時，需要依賴其它記憶體（指老年代）進行分配擔保。分配擔保就是，當另外一塊Survivor空間沒有足夠空間存放垃圾收集新生代存活下來的對象時，這些對象將直接通過記憶體分配擔保機制進入老年代。
標記-整理演算法
複製演算法在對象存活率比較高的時候，就要進行非常多的複製操作，使得效率變低。而且如果不想浪費50%的空間，就必須有額外一塊空間用作分配擔保，所以在老年代一般不會使用這種演算法。
根據老年代的特點，標記-整理（Mark-Compact）演算法應運而生，標記過程仍然與“標記-清除”演算法，但後續步驟不再是直接對可回收對象進行清除，而是讓所有存活對象都向一端移動，然後直接清理掉邊界以外的記憶體。
標記-整理演算法的執行過程如下圖：
分代收集演算法
“分代收集”（Generational Collection）演算法就是根據對象的存活周期的不同，將記憶體分為相應的幾塊。一般是把Java堆記憶體分為新生代和老年代，這樣可以根據各個年代的特點採用適合的收集演算法。在JDK1.7及之前，還有永久代，不過JDK1.8中已經被取消。
在新生代中，每次垃圾收集都有大批量的對象死去，只有少量存活，那就使用複製演算法，只需要付出少量存活對象的複製成本就可以完成收集。而老年代中對象存活率較高，也沒有額外空間進行分配擔保，所以就必須使用標記-清除或者標記-整理演算法來進行回收。
收集演算法的高效執行
上面介紹了幾個主流的垃圾收集演算法，垃圾收集演算法中需要判斷哪些對象是“存活”的哪些是“死亡”的，以決定具體回收哪些對象。上一篇文章中介紹的引用計數演算法以及可達性分析演算法，就是進行“對象審判”的依據。虛擬機在實現以上演算法的同時，也必須對演算法的執行效率進行嚴格的考量，才能保證虛擬機高效運行。
GC Roots
在可達性分析的時候，會從GC Roots節點查找引用鏈來作為判斷依據。而可以作為GC Roots的節點主要是在全局性的引用（例如常量或類靜態屬性），或者執行上下文（棧幀中的本地變數表）中。
另外，可達性分析的時間敏感還體現在GC停頓上，因為分析工作必須在一個能保證一致性的快照中進行，這裡的一致性是指分析期間整個執行系統就像凍結在某個時間點上，不能出現分析過程中對象引用關係還在不斷變化的情況。這點是導致GC進行時必須停頓所有執行線程的一個重要原因，這種GC停頓被稱作Stop-The-World。
目前主流的Java虛擬機採用的都是準確式GC，就是虛擬機可以知道記憶體中某個位置的數據具體是什麼類型，所以當GC停頓時，並不需要一個不漏的檢查所有引用，虛擬機有辦法可以直接得知哪些地方存放著對象引用。在HotSpot的實現中，是使用一組稱為OopMap的數據結構來達到這種目的，在類載入完後，HotSpot就把對象內什麼偏移量上是什麼類型的數據計算出來，在JIT編譯時，也會在特定的位置記錄下棧和寄存器中哪些位置是引用，這樣在GC掃描時就可以直接得知這些信息了。
安全點
程式執行時並非在所有地方都能停下來開始GC，只有在到達安全點（SafePoint）時才能暫停，因為只有在安全點的位置，才會記錄引用關係，才會記錄OopMap中的信息。安全點的選取是以“是否具有讓程式長時間執行的特征”為標準進行選定，而滿足長時間執行的特征就是指令序列復用，例如方法調用、迴圈跳轉、異常跳轉等，具有這些功能的指令才會產生SafePoint。
SafePoint的另一個問題就是如何在GC發生時讓所有線程都跑到最近的安全點上暫停下來，一般有兩種方法，分別是搶先式中斷和主動式中斷。搶先式中斷會在GC發生時首先把所有線程全部中斷，如果發現有線程中斷的地方不在安全點上，就恢複線程，讓它跑到安全點上。主動式中斷是當GC需要中斷線程的時候，不直接對線程操作，僅僅是簡單的設置一個標誌，各個線程主動去輪詢這個標誌，發現中斷標誌為真時就自己中斷掛起。比較多使用的是主動式中斷。
安全區域
安全點的機制看似已經完美了，但是實際卻不是。安全點機制可以保證在程式執行時，在不太長的時間內就能夠進入可以GC的SafePoint，但是當程式不執行的時候呢？所謂不執行就是不分配CPU時間，典型的例子就是線程Sleep或者Blocked狀態，這時線程無法響應JVM的中斷請求，從而跑到安全點去中斷掛起。這種情況，就只能通過安全區域（Safe Region）來解決了。
安全區域是指在一段代碼片段中，引用關係不會發生變化，在這個區域中的任何地方開始GC都是安全的。SafeRegion也可以看作是擴展了的SafePoint。
