一、 技術背景你要了解吧

按照套路是要先裝裝X，談談JVM垃圾回收的前世今生的。說起垃圾回收（GC），大部分人都把這項技術當做Java語言的伴生產物。事實上，GC的歷史比Java久遠，早在1960年Lisp這門語言中就使用了記憶體動態分配和垃圾回收技術。設計和優化C++這門語言的專家們要長點心啦~~

二、 哪些記憶體需要回收？

猿們都知道JVM的記憶體結構包括五大區域：程式計數器、虛擬機器棧、本地方法棧、堆區、方法區。其中程式計數器、虛擬機器棧、本地方法棧3個區域隨執行緒而生、隨執行緒而滅，因此這幾個區域的記憶體分配和回收都具備確定性，就不需要過多考慮回收的問題，因為方法結束或者執行緒結束時，記憶體自然就跟隨著回收了。而

垃圾收集器在對堆區和方法區進行回收前，首先要確定這些區域的物件哪些可以被回收，哪些暫時還不能回收，這就要用到判斷物件是否存活的演算法！（面試官肯定沒少問你吧）

2.1 引用計數演算法

2.1.1 演算法分析

引用計數是垃圾收集器中的早期策略。在這種方法中，堆中每個物件例項都有一個引用計數。當一個物件被建立時，就將該物件例項分配給一個變數，該變數計數設定為1。當任何其它變數被賦值為這個物件的引用時，計數加1（a = b,則b引用的物件例項的計數器+1），但當一個物件例項的某個引用超過了生命週期或者被設定為一個新值時，物件例項的引用計數器減

2.1.2 優缺點

優點：引用計數收集器可以很快的執行，交織在程式執行中。對程式需要不被長時間打斷的實時環境比較有利。

缺點：無法檢測出迴圈引用。如父物件有一個對子物件的引用，子物件反過來引用父物件。這樣，他們的引用計數永遠不可能為0。

2.1.3 是不是很無趣，來段程式碼壓壓驚

public class abc_test {
    public static void main(String[] args) {
        MyObject object1=new MyObject();
        MyObject object2
 
=new MyObject();
        
        object1.object=object2;
        object2.object=object1;
        
        object1=null;
        object2=null;
    }
}

class MyObject{
     MyObject object;
}

2.2 可達性分析演算法

可達性分析演算法是從離散數學中的圖論引入的，程式把所有的引用關係看作一張圖，從一個節點GC ROOT開始，尋找對應的引用節點，找到這個節點以後，繼續尋找這個節點的引用節點，當所有的引用節點尋找完畢之後，剩餘的節點則被認為是沒有被引用到的節點，即無用的節點，無用的節點將會被判定為是可回收的物件。

a) 虛擬機器棧中引用的物件（棧幀中的本地變量表）；

b) 方法區中類靜態屬性引用的物件；

c) 方法區中常量引用的物件；

d) 本地方法棧中JNI（Native方法）引用的物件。

這個演算法的基本思路就是通過一系列的稱為“GC Roots”的物件作為起始點，從這些節點開始向下搜尋，搜尋所走過的路徑稱為引用鏈（Reference Chain），當一個物件到GC Roots沒有任何引用鏈相連（用圖論的話來說，就是從GC Roots到這個物件不可達）時，則證明此物件是不可用的。如圖所示，物件object 5、object 6、object 7雖然互相有關聯，但是它們到GC Roots是不可達的，所以它們將會被判定為是可回收的物件。

現在問題來了，可達性分析演算法會不會出現物件間迴圈引用問題呢？答案是肯定的，那就是不會出現物件間迴圈引用問題。GC Root在物件圖之外，是特別定義的“起點”，不可能被物件圖內的物件所引用。

物件生存還是死亡(To Die Or Not To Die)

即使在可達性分析演算法中不可達的物件，也並非是“非死不可”的，這時候它們暫時處於“緩刑”階段，要真正宣告一個物件死亡，至少要經歷兩次標記過程：如果物件在進行可達性分析後發現沒有與GC Roots相連線的引用鏈，那它將會被第一次標記並且進行一次篩選，篩選的條件是此物件是否有必要執行finapze()方法。當物件沒有覆蓋finapze()方法，或者finapze()方法已經被虛擬機器呼叫過，虛擬機器將這兩種情況都視為“沒有必要執行”。程式中可以通過覆蓋finapze()來一場"驚心動魄"的自我拯救過程，但是，這隻有一次機會呦。

/**
 * 此程式碼演示了兩點：
 * 1.物件可以在被GC時自我拯救。
 * 2.這種自救的機會只有一次，因為一個物件的finapze()方法最多隻會被系統自動呼叫一次 
 * @author zzm
 */
pubpc class FinapzeEscapeGC {
  
 pubpc static FinapzeEscapeGC SAVE_HOOK = null;
  
 pubpc void isApve() {
  System.out.println("yes, i am still apve :)");
 }
  
 @Override
 protected void finapze() throws Throwable {
  super.finapze();
  System.out.println("finapze mehtod executed!");
  FinapzeEscapeGC.SAVE_HOOK = this;
 }
  
 pubpc static void main(String[] args) throws Throwable {
  SAVE_HOOK = new FinapzeEscapeGC();
  
  //物件第一次成功拯救自己
  SAVE_HOOK = null;
  System.gc();
  //因為finapze方法優先順序很低，所以暫停0.5秒以等待它
  Thread.sleep(500);
  if (SAVE_HOOK != null) {
SAVE_HOOK.isApve();
  } else {
System.out.println("no, i am dead :(");
  }
  
  //下面這段程式碼與上面的完全相同，但是這次自救卻失敗了
  SAVE_HOOK = null;
  System.gc();
  //因為finapze方法優先順序很低，所以暫停0.5秒以等待它
  Thread.sleep(500);
  if (SAVE_HOOK != null) {
SAVE_HOOK.isApve();
  } else {
System.out.println("no, i am dead :(");
  }
 }
}

finapze mehtod executed! 
yes, i am still apve :)
no, i am dead :(

2.3 Java中的引用你瞭解多少

無論是通過引用計數演算法判斷物件的引用數量，還是通過可達性分析演算法判斷物件的引用鏈是否可達，判定物件是否存活都與“引用”有關。在Java語言中，將引用又分為強引用、軟引用、弱引用、虛引用4種，這四種引用強度依次逐漸減弱。無論是通過引用計數演算法判斷物件的引用數量，還是通過可達性分析演算法判斷物件的引用鏈是否可達，判定物件是否存活都與“引用”有關。在JDK 1.2以前，Java中的引用的定義很傳統：如果reference型別的資料中儲存的數值代表的是另外一塊記憶體的起始地址，就稱這塊記憶體代表著一個引用。在JDK 1.2之後，Java對引用的概念進行了擴充，將引用分為強引用（Strong Reference）、軟引用（Soft Reference）、弱引用（Weak Reference）、虛引用（Phantom Reference）4種，這4種引用強度依次逐漸減弱。

2.3.1 強引用

在程式程式碼中普遍存在的，類似 Object obj = new Object() 這類引用，只要強引用還存在，垃圾收集器永遠不會回收掉被引用的物件。

2.3.2 軟引用

用來描述一些還有用但並非必須的物件。對於軟引用關聯著的物件，在系統將要發生記憶體溢位異常之前，將會把這些物件列進回收範圍之中進行第二次回收。如果這次回收後還沒有足夠的記憶體，才會丟擲記憶體溢位異常。

2.3.3 弱引用

也是用來描述非必需物件的，但是它的強度比軟引用更弱一些，被弱引用關聯的物件只能生存到下一次垃圾收集發生之前。當垃圾收集器工作時，無論當前記憶體是否足夠，都會回收掉只被弱引用關聯的物件。在JDK 1.2之後，提供了WeakReference類來實現弱引用。比如 threadlocal

2.3.4 虛引用

也叫幽靈引用或幻影引用（名字真會取，很魔幻的樣子），是最弱的一種引用 關係。一個物件是否有虛引用的存在，完全不會對其生存時間構成影響，也無法通過虛引用來取得一個物件例項。它的作用是能在這個物件被收集器回收時收到一個系統通知。。在JDK 1.2之後，提供了PhantomReference類來實現虛引用。

不要被概念嚇到，也別擔心，還沒跑題，再深入，可就不好說了。小編羅列這四個概念的目的是為了說明，無論引用計數演算法還是可達性分析演算法都是基於強引用而言的。

軟引用使用示例：

package jvm;
 
import java.lang.ref.SoftReference;
 
class Node {
pubpc String msg = "";
} 
pubpc class Hello {
pubpc static void main(String[] args) {
Node node1 = new Node(); // 強引用
node1.msg = "node1";
SoftReference<Node> node2 = new SoftReference<Node>(node1); // 軟引用
node2.get().msg = "node2";
 
System.out.println(node1.msg);
System.out.println(node2.get().msg);
}
}

node2
node2

2.4 物件死亡（被回收）前的最後一次掙扎

即使在可達性分析演算法中不可達的物件，也並非是“非死不可”，這時候它們暫時處於“緩刑”階段，要真正宣告一個物件死亡，至少要經歷兩次標記過程。

第一次標記：如果物件在進行可達性分析後發現沒有與GC Roots相連線的引用鏈，那它將會被第一次標記；

第二次標記：第一次標記後接著會進行一次篩選，篩選的條件是此物件是否有必要執行finalize()方法。在finalize()方法中沒有重新與引用鏈建立關聯關係的，將被進行第二次標記。

第二次標記成功的物件將真的會被回收，如果物件在finalize()方法中重新與引用鏈建立了關聯關係，那麼將會逃離本次回收，繼續存活。猿們還跟的上吧，嘿嘿。

2.5 方法區如何判斷是否需要回收

猿們，方法區儲存內容是否需要回收的判斷可就不一樣咯。方法區主要回收的內容有：廢棄常量和無用的類。對於廢棄常量也可通過引用的可達性來判斷，但是對於無用的類則需要同時滿足下面3個條件：

• 該類所有的例項都已經被回收，也就是Java堆中不存在該類的任何例項；
• 載入該類的ClassLoader已經被回收；
• 該類對應的java.lang.Class物件沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。

關於類載入的原理，也是阿里面試的主角，面試官也問過我比如：能否自己定義String，答案是不行，因為jvm在載入類的時候會執行雙親委派，

原理請參考：Java 類載入機制(阿里面試題)

講了半天，主角終於要粉墨登場了。

垃圾物件如何確定

Java堆中存放著幾乎所有的物件例項，垃圾收集器在對堆進行回收前，首先需要確定哪些物件還"活著"，哪些已經"死亡"，也就是不會被任何途徑使用的物件。

三、常用的垃圾收集演算法

3.0 引用計數法

引用計數法實現簡單，效率較高，在大部分情況下是一個不錯的演算法。其原理是：給物件新增一個引用計數器，每當有一個地方引用該物件時，計數器加1，當引用失效時，計數器減1，當計數器值為0時表示該物件不再被使用。需要注意的是：引用計數法很難解決物件之間相互迴圈引用的問題，主流Java虛擬機器沒有選用引用計數法來管理記憶體。

public class abc_test {
    public static void main(String[] args) {
        MyObject object1=new MyObject();
        MyObject object2=new MyObject();
        
        object1.object=object2;
        object2.object=object1;
        
        object1=null;
        object2=null;
    }
}

class MyObject{
     MyObject object;
}

這是最基礎的垃圾回收演算法，之所以說它是最基礎的是因為它最容易實現，思想也是最簡單的。標記-清除演算法分為兩個階段：標記階段和清除階段。標記階段的任務是標記出所有需要被回收的物件，清除階段就是回收被標記的物件所佔用的空間。具體過程如下圖所示：

從圖中可以很容易看出標記-清除演算法實現起來比較容易，但是有一個比較嚴重的問題就是容易產生記憶體碎片，碎片太多可能會導致後續過程中需要為大物件分配空間時無法找到足夠的空間而提前觸發新的一次垃圾收集動作。

標記-清除演算法採用從根集合（GC Roots）進行掃描，對存活的物件進行標記，標記完畢後，再掃描整個空間中未被標記的物件，進行回收，如下圖所示。標記-清除演算法不需要進行物件的移動，只需對不存活的物件進行處理，在存活物件比較多的情況下極為高效，但由於標記-清除演算法直接回收不存活的物件，因此會造成記憶體碎片。

3.2 複製演算法(Copying)

為了解決Mark-Sweep演算法的缺陷，Copying演算法就被提了出來。它將可用記憶體按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這一塊的記憶體用完了，就將還存活著的物件複製到另外一塊上面，然後再把已使用的記憶體空間一次清理掉，這樣一來就不容易出現記憶體碎片的問題。具體過程如下圖所示：

這種演算法雖然實現簡單，執行高效且不容易產生記憶體碎片，但是卻對記憶體空間的使用做出了高昂的代價，因為能夠使用的記憶體縮減到原來的一半。

很顯然，Copying演算法的效率跟存活物件的數目多少有很大的關係，如果存活物件很多，那麼Copying演算法的效率將會大大降低。

複製演算法的提出是為了克服控制代碼的開銷和解決記憶體碎片的問題。它開始時把堆分成 一個物件 面和多個空閒面， 程式從物件面為物件分配空間，當物件滿了，基於copying演算法的垃圾 收集就從根集合（GC Roots）中掃描活動物件，並將每個 活動物件複製到空閒面(使得活動物件所佔的記憶體之間沒有空閒洞)，這樣空閒面變成了物件面，原來的物件面變成了空閒面，程式會在新的物件面中分配記憶體。

3.3 標記-整理演算法(Mark-compact)

為了解決Copying演算法的缺陷，充分利用記憶體空間，提出了Mark-Compact演算法。該演算法標記階段和Mark-Sweep一樣，但是在完成標記之後，它不是直接清理可回收物件，而是將存活物件都向一端移動(美團面試題目，記住是完成標記之後，先不清理，先移動再清理回收物件)，然後清理掉端邊界以外的記憶體(美團問過)

標記-整理演算法採用標記-清除演算法一樣的方式進行物件的標記，但在清除時不同，在回收不存活的物件佔用的空間後，會將所有的存活物件往左端空閒空間移動，並更新對應的指標。標記-整理演算法是在標記-清除演算法的基礎上，又進行了物件的移動，因此成本更高，但是卻解決了記憶體碎片的問題。具體流程見下圖：

3.4 分代收集演算法 Generational Collection（分代收集）演算法

分代收集演算法是目前大部分JVM的垃圾收集器採用的演算法。它的核心思想是根據物件存活的生命週期將記憶體劃分為若干個不同的區域。一般情況下將堆區劃分為老年代（Tenured Generation）和新生代（Young Generation），在堆區之外還有一個代就是永久代（Permanet Generation）。老年代的特點是每次垃圾收集時只有少量物件需要被回收，而新生代的特點是每次垃圾回收時都有大量的物件需要被回收，那麼就可以根據不同代的特點採取最適合的收集演算法。

目前大部分垃圾收集器對於新生代都採取Copying演算法，因為新生代中每次垃圾回收都要回收大部分物件，也就是說需要複製的操作次數較少，但是實際中並不是按照1：1的比例來劃分新生代的空間的，一般來說是將新生代劃分為一塊較大的Eden空間和兩塊較小的Survivor空間（一般為8:1:1），每次使用Eden空間和其中的一塊Survivor空間，當進行回收時，將Eden和Survivor中還存活的物件複製到另一塊Survivor空間中，然後清理掉Eden和剛才使用過的Survivor空間。

而由於老年代的特點是每次回收都只回收少量物件，一般使用的是Mark-Compact演算法。

3.4.1 年輕代（Young Generation）的回收演算法 (回收主要以Copying為主)

a) 所有新生成的物件首先都是放在年輕代的。年輕代的目標就是儘可能快速的收集掉那些生命週期短的物件。

b) 新生代記憶體按照8:1:1的比例分為一個eden區和兩個survivor(survivor0,survivor1)區。一個Eden區，兩個 Survivor區(一般而言)。大部分物件在Eden區中生成。回收時先將eden區存活物件複製到一個survivor0區，然後清空eden區，當這個survivor0區也存放滿了時，則將eden區和survivor0區存活物件複製到另一個survivor1區，然後清空eden和這個survivor0區，此時survivor0區是空的，然後將survivor0區和survivor1區交換，即保持survivor1區為空(美團面試，問的太細，為啥保持survivor1為空，答案：為了讓eden和survivor0 交換存活物件)， 如此往復。當Eden沒有足夠空間的時候就會 觸發jvm發起一次Minor GC

c) 當survivor1區不足以存放 eden和survivor0的存活物件時，就將存活物件直接存放到老年代。若是老年代也滿了就會觸發一次Full GC(Major GC)，也就是新生代、老年代都進行回收。

d) 新生代發生的GC也叫做Minor GC，MinorGC發生頻率比較高(不一定等Eden區滿了才觸發)。

3.4.2 年老代（Old Generation）的回收演算法（回收主要以Mark-Compact為主）

a) 在年輕代中經歷了N次垃圾回收後仍然存活的物件，就會被放到年老代中。因此，可以認為年老代中存放的都是一些生命週期較長的物件。

b) 記憶體比新生代也大很多(大概比例是1:2)，當老年代記憶體滿時觸發Major GC即Full GC，Full GC發生頻率比較低，老年代物件存活時間比較長，存活率標記高。

3.4.3 持久代（Permanent Generation）(也就是方法區)的回收演算法

用於存放靜態檔案，如Java類、方法等。持久代對垃圾回收沒有顯著影響，但是有些應用可能動態生成或者呼叫一些class，例如Hibernate 等，在這種時候需要設定一個比較大的持久代空間來存放這些執行過程中新增的類。持久代也稱方法區，具體的回收可參見上文2.5節。

再寫一遍：

方法區儲存內容是否需要回收的判斷可就不一樣咯。方法區主要回收的內容有：廢棄常量和無用的類。對於廢棄常量也可通過引用的可達性來判斷，但是對於無用的類則需要同時滿足下面3個條件：

• 該類所有的例項都已經被回收，也就是Java堆中不存在該類的任何例項；
• 載入該類的ClassLoader已經被回收；
• 該類對應的java.lang.Class物件沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。

5、新生代和老年代的區別(阿里面試官的題目)：

**所謂的新生代和老年代是針對於分代收集演算法來定義的，新生代又分為Eden和Survivor兩個區。加上老年代就這三個區。資料會首先分配到Eden區 當中（當然也有特殊情況，如果是大物件那麼會直接放入到老年代（大物件是指需要大量連續記憶體空間的java物件）。），當Eden沒有足夠空間的時候就會 觸發jvm發起一次Minor GC。如果物件經過一次Minor GC還存活，並且又能被Survivor空間接受，那麼將被移動到Survivor空 間當中。並將其年齡設為1，物件在Survivor每熬過一次Minor GC，年齡就加1，當年齡達到一定的程度（預設為15）時，就會被晉升到老年代 中了，當然晉升老年代的年齡是可以設定的。如果老年代滿了就執行：Full GC 因為不經常執行，因此採用了 Mark-Compact演算法清理

其實新生代和老年代就是針對於物件做分割槽儲存，更便於回收等等**

猿們加油跟上，離offer不遠啦！！！

四、常見的垃圾收集器

下面一張圖是HotSpot虛擬機器包含的所有收集器，圖是借用過來滴：

• Serial收集器（複製演算法)

新生代單執行緒收集器，標記和清理都是單執行緒，優點是簡單高效。是client級別預設的GC方式，可以通過-XX:+UseSerialGC來強制指定。

• Serial Old收集器(標記-整理演算法)

老年代單執行緒收集器，Serial收集器的老年代版本。

• ParNew收集器(停止-複製演算法)　

新生代收集器，可以認為是Serial收集器的多執行緒版本,在多核CPU環境下有著比Serial更好的表現。

• Parallel Scavenge收集器(停止-複製演算法)

並行收集器，追求高吞吐量，高效利用CPU。吞吐量一般為99%， 吞吐量= 使用者執行緒時間/(使用者執行緒時間+GC執行緒時間)。適合後臺應用等對互動相應要求不高的場景。是server級別預設採用的GC方式，可用-XX:+UseParallelGC來強制指定，用-XX:ParallelGCThreads=4來指定執行緒數。

• Parallel Old收集器(停止-複製演算法)

Parallel Scavenge收集器的老年代版本，並行收集器，吞吐量優先。

• CMS(Concurrent Mark Sweep)收集器（標記-清理演算法）

高併發、低停頓，追求最短GC回收停頓時間，cpu佔用比較高，響應時間快，停頓時間短，多核cpu 追求高響應時間的選擇。

• CMS 和G1的垃圾回收器的原理，阿里的面試官也問過，我專門做了專題：
• 參考：圖解 CMS 垃圾回收機制原理，-阿里面試題
• 參考：CMS收集器和G1收集器優缺點-阿里面試題
• 參考：G1 垃圾收集器入門

五、GC是什麼時候觸發的（面試最常見的問題之一）

由於物件進行了分代處理，因此垃圾回收區域、時間也不一樣。GC有兩種型別：Scavenge GC和Full GC。

5.1 Scavenge GC

一般情況下，當新物件生成，並且在Eden申請空間失敗時，就會觸發Scavenge GC，對Eden區域進行GC，清除非存活物件，並且把尚且存活的物件移動到Survivor區。然後整理Survivor的兩個區。這種方式的GC是對年輕代的Eden區進行，不會影響到年老代。因為大部分物件都是從Eden區開始的，同時Eden區不會分配的很大，所以Eden區的GC會頻繁進行。因而，一般在這裡需要使用速度快、效率高的演算法，使Eden去能儘快空閒出來。

5.2 Full GC

對整個堆進行整理，包括Young、Tenured和Perm。Full GC因為需要對整個堆進行回收，所以比Scavenge GC要慢，因此應該儘可能減少Full GC的次數。在對JVM調優的過程中，很大一部分工作就是對於Full GC的調節。有如下原因可能導致Full GC：

a) 年老代（Tenured）被寫滿；

b) 持久代（Perm）被寫滿；

c) System.gc()被顯示呼叫；

d) 上一次GC之後Heap的各域分配策略動態變化；