1.JVM GC回收哪個區域的垃圾？

JVM GC只回收堆區和方法區內的物件，而堆疊區的資料，在超出作用域后會被JVM自動釋放掉，所以其不在JVM GC的管理范圍內，

2.判斷物件可以回收的方法

2.1 參考計數法

給物件中添加一個參考計數器，每當有一個地方參考它時，計數器值就加1；當參考失效時，計數器值就減1；任何時刻計數器為0的物件就是不可能再被使用的，

它的優點是簡單、高效，但是缺點也是例外明顯：這個方法無法解決物件回圈參考的問題

    // 物件回圈參考示例
    Object objectA = new Object();
    Object objectB = new Object();
    
    objectA.instance = objectB;
    objectB.instance = objectA;
    
    objectA = null;
    objectB = null;

假設我們有上面的代碼，程式啟動后，objectA和objectB兩個物件被創建并在堆中分配記憶體，它們都相互持有對方的參考，但是除了它們相互持有的參考之外，再無別的參考，而實際上，參考已經被置空，這兩個物件不可能再被訪問了，但是因為它們相互參考著對方，導致它們的參考計數都不為0，因此參考計數演算法無法通知GC回收它們，造成了記憶體的浪費，如下圖：物件之間的參考形成一個有環圖，

2.2 可達分析演算法

基于參考計數法無法回識訓圈應用，我們就有了一種新的方法，

可達分析演算法，或叫根搜索演算法，在主流的JVM中，都是使用的這種方法來判斷物件是否存活的，這個演算法的思路很簡單，它把記憶體中的每一個物件都看作一個結點，然后定義了一些可以作為根結點的物件，我們稱之為GC Roots，如果一個物件中有另一個物件的參考，那么就認這個物件有一條指向另一個物件的邊，

像上面這張圖，JVM會起一個執行緒從所有的GC Roots開始往下遍歷，當遍歷完之后如果發現有一些物件不可到達，那么就認為這些物件已經沒有用了，需要被回收，

上圖紅色為無用的節點，可以被回收，

需要注意的是：基本所有的GC演算法都參考根搜索演算法這種概念，

2.3 什么物件可以當作GC Roots？

共有四種物件可以作為GC Roots

虛擬機堆疊中的參考物件

我們在程式中正常創建一個物件時，物件會在堆上開辟一塊記憶體空間，同時會將這塊空間的地址作為參考保存到虛擬機堆疊中，如果物件生命周期結束了，那么參考就會從虛擬機堆疊中出堆疊，因此如果在虛擬機堆疊中有參考，就說明這個物件還是有用的，這種物件可以作為GC Roots，

全域的靜態的物件

也就是使用了static關鍵字定義了的物件，這種物件的參考保存在共有的方法區中，因為虛擬機堆疊是執行緒私有的，如果保存在堆疊里，就不叫全域了，很顯然，這種物件是要作為GC Roots的，

常量參考

就是使用了static final關鍵字，由于這種參考初始化之后不會修改，所以方法區常量池里的參考的物件也作為GC Roots，

本地方法堆疊中JNI參考的物件

有時候單純的java代碼不能滿足我們的需求，就可能需要呼叫C或C++代碼（java本身就是用C和C++寫的嘛），因此會使用native方法，JVM記憶體中專門有一塊本地方法堆疊，用來保存這些物件的參考，所以本地方法堆疊中參考的物件也會被作為GC Roots，

3.垃圾回收演算法

3.1 標記清除演算法

• 標記-清除演算法采用從根集合進行掃描，對存活的物件進行標記，標記完畢后，再掃描整個空間中未被標記的物件進行直接回收，如上圖，
• 標記-清除演算法不需要進行物件的移動，并且僅對不存活的物件進行處理，在存活的物件比較多的情況下極為高效，但由于標記-清除演算法直接回收不存活的物件，并沒有對還存活的物件進行整理，因此會導致記憶體碎片，

3.2 復制演算法

• 復制演算法將記憶體分為兩個空間，使用此演算法時，所有動態分配的物件都只能分配在其中一個區間（活動區間），而另外一個區間（空閑區間）則是空閑的，
• 復制演算法采用從根集合掃描，將存活的物件復制到空閑區間，當掃描完畢活動區間后，會將活動區間一次性全部回收，此時原本的空閑區間變成了活動區間，下次GC時候又會重復剛才的操作，以此回圈，
• 復制演算法在存活物件比較少的時候，極為高效，但是帶來的成本是犧牲一半的記憶體空間用于進行物件的移動，所以復制演算法的使用場景，必須是物件的存活率非常低才行，而且最重要的是，我們需要克服50%記憶體的浪費，

3.3 標記壓縮演算法

• 標記-壓縮演算法采用和 標記-清除 演算法一樣的方式進行物件的標記、清除，但在回收不存活的物件占用的空間后，會將所有存活的物件往左端空閑空間移動，并更新對應的指標，標記-清除 演算法是在標記-清除 演算法之上，又進行了物件的移動排序整理，因此成本更高，但卻解決了記憶體碎片的問題，

3.4 分代回收演算法

• 根據存活物件劃分幾塊記憶體區域，一般是分為新生代和老年代，然后根據各個年代的特點制定相應的回收演算法，

年輕代復制演算法的具體應用：

生成空間好比就是eden區，survivor分別是From幸存區、To幸存區，eden區會標記一些存活的物件拷貝到From區，然后清空eden區，

如果From區和eden區都有垃圾，就把eden區和From區都存活的物件全部拷貝到To區，然后清空eden區和From區

如果To區和eden區都有垃圾，就把eden區和To區都存活的物件全部拷貝到From區，然后清空eden區和To區

反復回圈，默認來回回圈15次，如果活動的物件還是沒有被垃圾回收器回收了，就存放到老年代

• 新生代（new / Young）

  • 每次垃圾回收都有大量的物件死去，只有少量物件存活，選用復制演算法比較合理，
  • 新生代回收可以稱為：YGC

• 老年代（old）

  • 老年代中物件的存活率較高，沒有額外的空間分配對它進行擔保，所以必須使用標記-清除或者標記-壓縮演算法進行垃圾回收，
  • 老年代回收可以稱為：MGC

• 整體回收可以稱為：FGC

4.垃圾回收器

理解什么是STW？

• 在垃圾回收時，都會產生應用程式的停頓，停頓產生時，整個應用程式會被卡死，沒有任何回應，
• java中Stop-The-World機制簡稱STW，是在執行垃圾收集演算法時，Java應用程式的其他業務執行緒都被掛起（除了垃圾收集幫助器之外），
• Java中一種全域暫停現象，全域停頓，所有Java代碼停止，native代碼可以執行，但不能與JVM互動；這些現象多半是由于GC引起，
• 沒有一種垃圾回收器不會產生STW，就連CMS這種多執行緒并發執行的回收器也會產生STW
• CMS產生STW的階段剛好就在初始標記和重新標記階段

說明：如果兩個垃圾回收器之間存在連線說明他們之間是可以搭配使用的

4.1 Serial 和 Serial Old 回收器

• Serial分為Serial、Serial Old，其中Serial作業在年輕代，Serial Old作業在老年代
• Serial是單執行緒的垃圾回收器，當垃圾回收執行緒開始的時候，業務執行緒必須暫停，直到垃圾回收執行緒結束
• Serial使用的是復制演算法，而Serial Old使用的是標記-壓縮演算法

4.2 ParNew 回收器

• ParNew可以認為是Serial的多執行緒版本
• ParNew是多執行緒并行的，也就是說當多條垃圾回收執行緒并行作業時，此時的業務執行緒處于等待狀態

4.3 Parallel Scavenge 回收器

• Parallel Scavenge 是一個年輕代的垃圾回收器，也就是說Parallel作業在年輕代
• Parallel Scavenge是多執行緒并行的，也就是說當多條垃圾回收執行緒并行作業時，此時的業務執行緒處于等待狀態
• 采用復制演算法實作
• JDK1.8默認采用的垃圾回收器：Parallel Scavenge、Parallel Old

4.4 Parallel Old 回收器

• Parallel Old 是 Parallel Scavenge 的老年代版本，也就是說Parallel Old作業在老年代
• Parallel Old是多執行緒并行的，也就是說當多條垃圾回收執行緒并行作業時，此時的業務執行緒處于等待狀態
• 采用標記-壓縮演算法

4.5 CMS 回收器（重點）

• CMS (Concurrent Mark Sweep) 收集器是一種以獲取最短回收停頓時間為目標的收集器，
• CMS是多執行緒并發的，也就是說垃圾執行緒和業務行程是可以一起執行的
• 采用 標記-清除 演算法實作，
• 運行步驟：
  • 初始標記(CMS initial mark)：標記 GC Roots 能直接關聯到的物件
  • 并發標記(CMS concurrent mark)：進行 GC Roots Tracing
  • 重新標記(CMS remark)：修正并發標記期間的變動部分
    • 這里要注意：重新標記就不能業務執行緒和垃圾執行緒一起執行了，也就是不能并發執行了
  • 并發清除(CMS concurrent sweep)

4.5.1 并發標記出現的問題：漏標和錯標

• 并發標記雖然說垃圾執行緒和業務執行緒一起執行，但是這種情況也會產生各種問題
• 漏標：一個物件被GC標記為不是垃圾，但是隨著業務的進行，該物件的參考消失了，就變成了垃圾，而這時垃圾回收并沒有標記該物件為垃圾，這時候就會產生漏標的情況
  • 這就是著名的"浮動垃圾(floating garbage)"
  • 解決辦法很簡單，下次垃圾執行緒再回圈的時候，該物件會被重新標記為垃圾，進行清理
• 錯標：一個物件被GC標記為垃圾，但是隨著業務的進行，該物件被其他物件參考了，又變成不是垃圾了，而這時垃圾回收已經標記為該物件是垃圾了，這時候就會產生錯標的情況

4.5.2 并發標記問題的解決：三色標記演算法

漏標問題

1. 某個狀態下,黑色->灰色->白色

2. 如果一切順利，不發生任何參考變化，GC執行緒順著灰色的參考向下掃描，最后都變成黑色，都是存活物件

3. 但是如果出現了這樣一個狀況，在掃描到灰色的時候，還沒有掃描到這個白色物件，此時，黑色物件參考了這個白色物件，而灰色物件指向了別人，或者干脆指向了null，也就是取消了對白色物件的參考

4. 那么我們會發現一個問題，根據三色標記規則，GC會認為，黑色物件是本身已經被掃描過，并且它所有指向的參考都已經被掃描過，所以不會再去掃描它有哪些參考指向了哪些物件

然后,灰色物件因為取消了對白色物件的參考,所以后面GC開始掃描所有灰色物件的參考時候,也不會再掃描到白色物件

最后結果就是,白色物件直到本次標記掃描結束,也是白色,根據三色標記規則,認為它是垃圾,被清理掉

但是實際情況,它明顯是被參考的物件,是絕對不能當做垃圾來清除的,因為漏標,最后被當作垃圾清理掉了
  
/*
漏標的兩個充要條件:
1.有至少一個黑色物件在自己被標記之后指向了這個白色物件
2.所有的灰色物件在自己參考掃描完成之前洗掉了對白色物件的參考
這兩個條件,必須全滿足,才會造成漏標問題.
*/

5. CMS的解決方案就是重新標記：將A變成灰色，問題解決

4.5.3 CMS巨大bug

記住一句話：沒有任何一個jdk版本的默認垃圾回收器是cms

4.6 G1 回收器

• G1是面向服務端的垃圾回收器，
• 優點：并行與并發、分代收集、空間整合、可預測停頓，
• 運作步驟：
  • 初始標記(Initial Marking)
  • 并發標記(Concurrent Marking)
  • 最終標記(Final Marking)
  • 篩選回收(Live Data Counting and Evacuation)