深入理解JVM的垃圾回收機(jī)制

1、如何判斷對(duì)象已“死”

Java堆中存放著幾乎所有的對(duì)象實(shí)例，垃圾回收器在堆進(jìn)行垃圾回收前，首先要判斷這些對(duì)象那些還存活，那些已經(jīng)“死去”。判斷對(duì)象是否已“死”有如下幾種算法：

1.1 引用計(jì)數(shù)法

引用計(jì)數(shù)法描述的算法為：給對(duì)象增加一個(gè)引用計(jì)數(shù)器，每當(dāng)有一個(gè)地方引用它時(shí)，計(jì)數(shù)器就+1；當(dāng)引用失效時(shí)，計(jì)數(shù)器就-1；任何時(shí)刻計(jì)數(shù)器為0的對(duì)象就是不能再被使用的，即對(duì)象已“死”。

引用計(jì)數(shù)法實(shí)現(xiàn)簡單，判定效率也比較高，在大部分情況下都是一個(gè)比較好的算法。比如Python語言就是采用的引用計(jì)數(shù)法來進(jìn)行內(nèi)存管理的。

但是，在主流的JVM中沒有選用引用計(jì)數(shù)法來管理內(nèi)存，最主要的原因是引用計(jì)數(shù)法無法解決對(duì)象的循環(huán)引用問題。

范例：循環(huán)引用問題

/**
  * JVM參數(shù):-XX:+PrintGC
  *
*/
public class Test {
 public Object instance = null;
 private static int _1MB = 1024 * 1024;
 private byte[] bigSize = new byte[2 * _1MB];
 public static void testGC() {
  Test test1 = new Test();
  Test test2 = new Test();
  test1.instance = test2;
  test2.instance = test1;
  test1 = null;
  test2 = null;
  // 強(qiáng)制JVM進(jìn)行垃圾回收
  System.gc();
 }
 public static void main(String[] args) {
  testGC();
 }
}

程序輸出：[GC (System.gc()) 6092K->856K(125952K), 0.0007504 secs]

從結(jié)果可以看出，GC日志包含" 6092K->856K(125952K)"，意味著虛擬機(jī)并沒有因?yàn)檫@兩個(gè)對(duì)象互相引用就不回收他們。即JVM并不使用引用計(jì)數(shù)法來判斷對(duì)象是否存活。

1.2 可達(dá)性分析算法

在上面講了，Java并不采用引用計(jì)數(shù)法來判斷對(duì)象是否已“死”，而采用“可達(dá)性分析”來判斷對(duì)象是否存活（同樣采用此法的還有C#、Lisp-最早的一門采用動(dòng)態(tài)內(nèi)存分配的語言）。

此算法的核心思想：通過一系列稱為“GC Roots”的對(duì)象作為起始點(diǎn)，從這些節(jié)點(diǎn)開始向下搜索，搜索走過的路徑稱為“引用鏈”，當(dāng)一個(gè)對(duì)象到 GC Roots 沒有任何的引用鏈相連時(shí)(從 GC Roots 到這個(gè)對(duì)象不可達(dá))時(shí)，證明此對(duì)象不可用。以下圖為例：

對(duì)象Object5 —Object7之間雖然彼此還有聯(lián)系，但是它們到 GC Roots 是不可達(dá)的，因此它們會(huì)被判定為可回收對(duì)象。

在Java語言中，可作為GC Roots的對(duì)象包含以下幾種：

（1）虛擬機(jī)棧(棧幀中的本地變量表)中引用的對(duì)象。

（2）方法區(qū)中靜態(tài)屬性引用的對(duì)象

（3）方法區(qū)中常量引用的對(duì)象

（4）本地方法棧中(Native方法)引用的對(duì)象

在JDK1.2以前，Java中引用的定義很傳統(tǒng): 如果引用類型的數(shù)據(jù)中存儲(chǔ)的數(shù)值代表的是另一塊內(nèi)存的起始地址，就稱這塊內(nèi)存代表著一個(gè)引用。這種定義有些狹隘，一個(gè)對(duì)象在這種定義下只有被引用或者沒有被引用兩種狀態(tài)。

我們希望能描述這一類對(duì)象: 當(dāng)內(nèi)存空間還足夠時(shí)，則能保存在內(nèi)存中；如果內(nèi)存空間在進(jìn)行垃圾回收后還是非常緊張，則可以拋棄這些對(duì)象。很多系統(tǒng)中的緩存對(duì)象都符合這樣的場景。

在JDK1.2之后，Java對(duì)引用的概念做了擴(kuò)充，將引用分為強(qiáng)引用(Strong Reference)、軟引用(Soft Reference)、弱引用(Weak Reference)和虛引用(Phantom Reference)四種，這四種引用的強(qiáng)度依次遞減。

（1）強(qiáng)引用: 強(qiáng)引用指的是在程序代碼之中普遍存在的，類似于"Object obj = new Object()"這類的引用，只要強(qiáng)引用還存在，垃圾回收器永遠(yuǎn)不會(huì)回收掉被引用的對(duì)象實(shí)例。

（2）軟引用: 軟引用是用來描述一些還有用但是不是必須的對(duì)象。對(duì)于軟引用關(guān)聯(lián)著的對(duì)象，在系統(tǒng)將要發(fā)生內(nèi)存溢出之前，會(huì)把這些對(duì)象列入回收范圍之中進(jìn)行第二次回收。如果這次回收還是沒有足夠的內(nèi)存，才會(huì)拋出內(nèi)存溢出異常。在JDK1.2之后，提供了SoftReference類來實(shí)現(xiàn)軟引用。

（3）弱引用: 弱引用也是用來描述非必需對(duì)象的。但是它的強(qiáng)度要弱于軟引用。被弱引用關(guān)聯(lián)的對(duì)象只能生存到下一次垃圾回收發(fā)生之前。當(dāng)垃圾回收器開始進(jìn)行工作時(shí)，無論當(dāng)前內(nèi)容是否夠用，都會(huì)回收掉只被弱引用關(guān)聯(lián)的對(duì)象。在JDK1.2之后提供了WeakReference類來實(shí)現(xiàn)弱引用。

（4）虛引用: 虛引用也被稱為幽靈引用或者幻影引用，它是最弱的一種引用關(guān)系。一個(gè)對(duì)象是否有虛引用的存在，完全不會(huì)對(duì)其生存時(shí)間構(gòu)成影響，也無法通過虛引用來取得一個(gè)對(duì)象實(shí)例。為一個(gè)對(duì)象設(shè)置虛引用的唯一目的就是能在這個(gè)對(duì)象被收集器回收時(shí)收到一個(gè)系統(tǒng)通知。在JDK1.2之后，提供了PhantomReference類來實(shí)現(xiàn)虛引用。

生存還是死亡？

即使在可達(dá)性分析算法中不可達(dá)的對(duì)象，也并非"非死不可"的，這時(shí)候他們暫時(shí)處在"緩刑"階段。要宣告一個(gè)對(duì)象的真正死亡，至少要經(jīng)歷兩次標(biāo)記過程: 如果對(duì)象在進(jìn)行可達(dá)性分析之后發(fā)現(xiàn)沒有與GC Roots相連接的引用鏈，那它將會(huì)被第一次標(biāo)記并且進(jìn)行一次篩選，篩選的條件是此對(duì)象是否有必要執(zhí)行?nalize()方法。當(dāng)對(duì)象沒有覆蓋?nalize()方法或者?nalize()方法已經(jīng)被JVM調(diào)用過，虛擬機(jī)會(huì)將這兩種情況都視為"沒有必要執(zhí)行"，此時(shí)的對(duì)象才是真正"死"的對(duì)象。

如果這個(gè)對(duì)象被判定為有必要執(zhí)行?nalize()方法，那么這個(gè)對(duì)象將會(huì)被放置在一個(gè)叫做F-Queue的隊(duì)列之中，并在稍后由一個(gè)虛擬機(jī)自動(dòng)建立的、低優(yōu)先級(jí)的Finalizer線程去執(zhí)行它（這里所說的執(zhí)行指的是虛擬機(jī)會(huì)觸發(fā)?nalize()方法）。?nalize()方法是對(duì)象逃脫死亡的最后一次機(jī)會(huì)，稍后GC將對(duì)F-Queue中的對(duì)象進(jìn)行第二次小規(guī)模標(biāo)記，如果對(duì)象在?nalize()中成功拯救自己(只需要重新與引用鏈上的任何一個(gè)對(duì)象建立起關(guān)聯(lián)關(guān)系即可)，那在第二次標(biāo)記時(shí)它將會(huì)被移除出"即將回收"的集合；如果對(duì)象這時(shí)候還是沒有逃脫，那基本上它就是真的被回收了。

范例：對(duì)象自我拯救

public class Test {
 public static Test test;
 public void isAlive() {
  System.out.println("I am alive :)");
 }
 @Override
 protected void finalize() throws Throwable {
  super.finalize();
  System.out.println("finalize method executed!");
  test = this;
 }
 public static void main(String[] args)throws Exception {
  test = new Test();
  test = null;
  System.gc();
  Thread.sleep(500);
  if (test != null) {
   test.isAlive();
  }else {
   System.out.println("no,I am dead :(");
  }
  // 下面代碼與上面完全一致，但是此次自救失敗
  test = null;
  System.gc();
  Thread.sleep(500);
  if (test != null) {
   test.isAlive();
  }else {
   System.out.println("no,I am dead :(");
  }
 }
}

從上面代碼示例我們發(fā)現(xiàn)，?nalize方法確實(shí)被JVM觸發(fā)，并且對(duì)象在被收集前成功逃脫。

但是從結(jié)果上我們發(fā)現(xiàn)，兩個(gè)完全一樣的代碼片段，結(jié)果是一次逃脫成功，一次失敗。這是因?yàn)?，任何一個(gè)對(duì)象的?nalize()方法都只會(huì)被系統(tǒng)自動(dòng)調(diào)用一次，如果相同的對(duì)象在逃脫一次后又面臨一次回收，它的?nalize()方法不會(huì)被再次執(zhí)行，因此第二段代碼的自救行動(dòng)失敗。

2、回收方法區(qū)

方法區(qū)(永久代)的垃圾回收主要收集兩部分內(nèi)容：廢棄常量和無用類。

回收廢棄常量和回收J(rèn)ava堆中的對(duì)象十分類似。以常量池中字面量(直接量)的回收為例，假如一個(gè)字符串"abc"怡景進(jìn)入了常量池中，但是當(dāng)前系統(tǒng)沒有任何一個(gè)String對(duì)象引用常量池中的"abc"常量，也沒有其他地方引用這個(gè)字面量，如果此時(shí)發(fā)生GC并且有必要的話，這個(gè)"abc"常量會(huì)被系統(tǒng)清理出常量池。常量池中的其他類(接口)、方法、字段的符號(hào)引用也與此類似。

判定一個(gè)類是否是"無用類"則相對(duì)復(fù)雜很多。類需要同時(shí)滿足下面三個(gè)條件才會(huì)被算是"無用的類"

1.該類的所有實(shí)例都已經(jīng)被回收(即在Java堆中不存在任何該類的實(shí)例)

2.加載該類的ClassLoader已被回收

3.該類對(duì)應(yīng)的Class對(duì)象沒有任何其他地方被引用，無法在任何地方通過反射訪問該類的方法

JVM可以對(duì)同時(shí)滿足上述3個(gè)條件的無用類進(jìn)行回收，也僅僅是“可以”而不是必然。在大量使用反射、動(dòng)態(tài)代理等場景都需要JVM具備類卸載的功能來防止永久代的溢出。

3、垃圾回收算法

3.1 標(biāo)記-清除算法

“標(biāo)記-清除”算法是最基礎(chǔ)的收集算法。算法分為標(biāo)記和清除兩個(gè)階段：首先標(biāo)記出所有需要回收的對(duì)象，在標(biāo)記完成后統(tǒng)一回收所有被標(biāo)記的對(duì)象(標(biāo)記過程參見1.2可達(dá)性分析)。后續(xù)的收集算法都是基于這種思路并對(duì)其不足加以改進(jìn)而已。

“標(biāo)記-清除”算法的不足主要有兩個(gè)：

（1）效率問題：標(biāo)記和清除這兩個(gè)過程的效率都不高

（2）空間問題：標(biāo)記清除后會(huì)產(chǎn)生大量不連續(xù)的內(nèi)存碎片，空間碎片太多可能會(huì)導(dǎo)致以后在程序運(yùn)行中需要分配較大對(duì)象時(shí)，無法找到足夠連續(xù)內(nèi)存而不得不提前觸發(fā)另一次垃圾收集。

3.2 復(fù)制算法(新生代回收算法)

“復(fù)制”算法是為了解決“標(biāo)記-清除”的效率問題。它將可用內(nèi)存按容量劃分為大小相等的兩塊，每次只使用其中一塊。當(dāng)這塊內(nèi)存需要進(jìn)行垃圾回收時(shí)，會(huì)將此區(qū)域還存活著的對(duì)象復(fù)制到另一塊上面，然后再把已經(jīng)使用過的內(nèi)存區(qū)域一次清理掉。這樣做的好處是每次都是對(duì)整個(gè)半?yún)^(qū)進(jìn)行內(nèi)存回收，內(nèi)存分配時(shí)也就不需要考慮內(nèi)存碎片等的復(fù)雜情況，只需要移動(dòng)堆頂指針，按順序分配即可。此算法實(shí)現(xiàn)簡單，運(yùn)行高效。算法的執(zhí)行流程如下圖：

現(xiàn)在的商用虛擬機(jī)(包括HotSpot)都是采用這種收集算法來回收新生代

新生代中98%的對(duì)象都是"朝生夕死"的，所以并不需要按照1 : 1的比例來劃分內(nèi)存空間，而是將內(nèi)存(新生代內(nèi)存)分為一塊較大的Eden(伊甸園)空間和兩塊較小的Survivor(幸存者)空間，每次使用Eden和其中一塊Survivor（兩個(gè)Survivor區(qū)域一個(gè)稱為From區(qū)，另一個(gè)稱為To區(qū)域）。當(dāng)回收時(shí)，將Eden和Survivor中還存活的對(duì)象一次性復(fù)制到另一塊Survivor空間上，最后清理掉Eden和剛才用過的Survivor空間。

當(dāng)Survivor空間不夠用時(shí)，需要依賴其他內(nèi)存(老年代)進(jìn)行分配擔(dān)保。

HotSpot默認(rèn)Eden與Survivor的大小比例是8 : 1，也就是說Eden:Survivor From : Survivor To = 8:1:1。所以每次新生代可用內(nèi)存空間為整個(gè)新生代容量的90%,而剩下的10%用來存放回收后存活的對(duì)象。

HotSpot實(shí)現(xiàn)的復(fù)制算法流程如下：

（1）當(dāng)Eden區(qū)滿的時(shí)候，會(huì)觸發(fā)第一次Minor gc，把還活著的對(duì)象拷貝到Survivor From區(qū)；當(dāng)Eden區(qū)再次出發(fā)Minor gc的時(shí)候，會(huì)掃描Eden區(qū)和From區(qū)，對(duì)兩個(gè)區(qū)域進(jìn)行垃圾回收，經(jīng)過這次回收后還存活的對(duì)象，則直接復(fù)制到To區(qū)域，并將Eden區(qū)和From區(qū)清空。

（2）當(dāng)后續(xù)Eden區(qū)又發(fā)生Minor gc的時(shí)候，會(huì)對(duì)Eden區(qū)和To區(qū)進(jìn)行垃圾回收，存活的對(duì)象復(fù)制到From區(qū)，并將Eden區(qū)和To區(qū)清空

（3）部分對(duì)象會(huì)在From區(qū)域和To區(qū)域中復(fù)制來復(fù)制去，如此交換15次(由JVM參數(shù)MaxTenuringThreshold決定，這個(gè)參數(shù)默認(rèn)是15)，最終如果還存活，就存入老年代。

3.3 標(biāo)記整理算法(老年代回收算法)

復(fù)制收集算法在對(duì)象存活率較高時(shí)會(huì)進(jìn)行比較多的復(fù)制操作，效率會(huì)變低。因此在老年代一般不能使用復(fù)制算法。

針對(duì)老年代的特點(diǎn)，提出了一種稱之為“標(biāo)記-整理算法”。標(biāo)記過程仍與“標(biāo)記-清除”過程一致，但后續(xù)步驟不是直接對(duì)可回收對(duì)象進(jìn)行清理，而是讓所有存活對(duì)象向一端移動(dòng)，然后直接清理掉端邊界以外的內(nèi)存。流程圖如下：

3.4 分代收集算法

當(dāng)前JVM垃圾收集都采用的是"分代收集(Generational Collection)"算法，這個(gè)算法并沒有新思想，只是根據(jù)對(duì)象存活周期的不同將內(nèi)存劃分為幾塊。

一般是把Java堆分為新生代和老年代。在新生代中，每次垃圾回收都有大批對(duì)象死去，只有少量存活，因此我們采用復(fù)制算法；而老年代中對(duì)象存活率高、沒有額外空間對(duì)它進(jìn)行分配擔(dān)保，就必須采用"標(biāo)記-清理"或者"標(biāo)記-整理"算法。

面試題: 請(qǐng)問了解Minor GC和Full GC么，這兩種GC有什么不一樣嗎？

（1）Minor GC又稱為新生代GC : 指的是發(fā)生在新生代的垃圾收集。因?yàn)镴ava對(duì)象大多都具備朝生夕滅的特性，因此Minor GC(采用復(fù)制算法)非常頻繁，一般回收速度也比較快。

（2）Full GC 又稱為老年代GC或者M(jìn)ajor GC : 指發(fā)生在老年代的垃圾收集。出現(xiàn)了Major GC，經(jīng)常會(huì)伴隨至少一次的Minor GC(并非絕對(duì)，在Parallel Scavenge收集器中就有直接進(jìn)行Full GC的策略選擇過程)。Major GC的速度一般會(huì)比Minor GC慢10倍以上。

原文鏈接：

https://blog.csdn.net/yubujian_l/article/details/80804708