什么是JVM

JVM 是可運(yùn)行 Java 代碼的假想計(jì)算機(jī) ，包括一套字節(jié)碼指令集、一組寄存器、一個(gè)棧、一個(gè)垃圾回收，堆 和 一個(gè)存儲(chǔ)方法域。JVM 是運(yùn)行在操作系統(tǒng)之上的，它與硬件沒有直接的交互。

線程

這里所說的線程指程序執(zhí)行過程中的一個(gè)線程實(shí)體。JVM 允許一個(gè)應(yīng)用并發(fā)執(zhí)行多個(gè)線程 。Hotspot JVM 中的 Java 線程與原生操作系統(tǒng)線程有直接的映射關(guān)系。當(dāng)線程本地存儲(chǔ)、緩沖區(qū)分配、同步對(duì)象、棧、程序計(jì)數(shù)器等準(zhǔn)備好以后，就會(huì)創(chuàng)建一個(gè)操作系統(tǒng)原生線程。Java 線程結(jié)束，原生線程隨之被回收。操作系統(tǒng)負(fù)責(zé)調(diào)度所有線程，并把它們分配到任何可用的 CPU 上。當(dāng)原生線程初始化完畢，就會(huì)調(diào)用 Java 線程的 run() 方法。當(dāng)線程結(jié)束時(shí)，會(huì)釋放原生線程和 Java 線程的所有資源。

• Hotspot JVM 后臺(tái)運(yùn)行的系統(tǒng)線程主要有下面幾個(gè)：

• 虛擬機(jī)線程:這個(gè)線程等待 JVM 到達(dá)安全點(diǎn)操作出現(xiàn)。這些操作必須要在獨(dú)立的線程里執(zhí)行，因?yàn)楫?dāng)堆修改無法進(jìn)行時(shí)，線程都需要 JVM位于安全點(diǎn)。這些操作的類型有：stop-the-world 垃圾回收、線程棧dump、線程暫停、線程偏向鎖（biased  locking）解除。

• 周期性任務(wù)線程:這線程負(fù)責(zé)定時(shí)器事件（也就是中斷），用來調(diào)度周期性操作的執(zhí)行。

• GC 線程  :這些線程支持 JVM 中不同的垃圾回收活動(dòng)。

• 編譯器線程:這些線程在運(yùn)行時(shí)將字節(jié)碼動(dòng)態(tài)編譯成本地平臺(tái)相關(guān)的機(jī)器碼。

• 信號(hào)分發(fā)線程:這個(gè)線程接收發(fā)送到 JVM 的信號(hào)并調(diào)用適當(dāng)?shù)?JVM 方法處理。

JVM內(nèi)存區(qū)域

• JVM 內(nèi)存區(qū)域主要分為線程私有區(qū)域【程序計(jì)數(shù)器、虛擬機(jī)棧、本地方法區(qū)】、線程共享區(qū)域【JAVA 堆、方法區(qū)】、直接內(nèi)存。
  -線程私有數(shù)據(jù)區(qū)域生命周期與線程相同, 依賴用戶線程的啟動(dòng)/結(jié)束 而 創(chuàng)建/銷毀(在 HotspotVM 內(nèi), 每個(gè)線程都與操作系統(tǒng)的本地線程直接映射, 因此這部分內(nèi)存區(qū)域的存/否跟隨本地線程的生/死對(duì)應(yīng))。

• 線程共享區(qū)域隨虛擬機(jī)的啟動(dòng)/關(guān)閉而創(chuàng)建/銷毀。

程序計(jì)數(shù)器( 線程私有）

• 一塊較小的內(nèi)存空間, 是當(dāng)前線程所執(zhí)行的字節(jié)碼的行號(hào)指示器，每條線程都要有一個(gè)獨(dú)立的程序計(jì)數(shù)器，這類內(nèi)存也稱為“線程私有”的內(nèi)存。

• 正在執(zhí)行 java 方法的話，計(jì)數(shù)器記錄的是虛擬機(jī)字節(jié)碼指令的地址（當(dāng)前指令的地址）。如果還是 Native 方法，則為空。

• 這個(gè)內(nèi)存區(qū)域是唯一一個(gè)在虛擬機(jī)中沒有規(guī)定任OutOfMemoryError 情況的區(qū)域。

JAVA虛擬機(jī)棧( 線程私有)

• 是描述java方法執(zhí)行的內(nèi)存模型，每個(gè)方法在執(zhí)行的同時(shí)都會(huì)創(chuàng)建一個(gè)棧幀（Stack Frame）用于存儲(chǔ)局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法出口等信息。每一個(gè)方法從調(diào)用直至執(zhí)行完成的過程，就對(duì)應(yīng)著一個(gè)棧幀在虛擬機(jī)棧中入棧到出棧的過程。

• 棧幀（ Frame）是用來存儲(chǔ)數(shù)據(jù)和部分過程結(jié)果的數(shù)據(jù)結(jié)構(gòu)，同時(shí)也被用來處理動(dòng)態(tài)鏈接(Dynamic Linking)、 方法返回值和異常分派（ Dispatch Exception）。棧幀隨著方法調(diào)用而創(chuàng)建，隨著方法結(jié)束而銷毀——無論方法是正常完成還是異常完成（拋出了在方法內(nèi)未被捕獲的異常）都算作方法結(jié)束。
  

  

本地方法區(qū)(線程私有）

• 本地方法區(qū)和 Java Stack 作用類似, 區(qū)別是虛擬機(jī)棧為執(zhí)行 Java 方法服務(wù), 而本地方法棧則為Native 方法服務(wù), 如果一個(gè) VM 實(shí)現(xiàn)使用 C-linkage 模型來支持 Native 調(diào)用, 那么該棧將會(huì)是一個(gè)C 棧，但 HotSpot VM 直接就把本地方法棧和虛擬機(jī)棧合二為一。

堆（Heap- 線程共享）運(yùn)行時(shí)數(shù)據(jù)區(qū)

• 是被線程共享的一塊內(nèi)存區(qū)域，創(chuàng)建的對(duì)象和數(shù)組都保存在 Java 堆內(nèi)存中，也是垃圾收集器進(jìn)行垃圾收集的最重要的內(nèi)存區(qū)域。由于現(xiàn)代 VM 采用分代收集算法, 因此 Java 堆從 GC 的角度還可以細(xì)分為: 新生代( Eden 區(qū) 、 From Survivor 區(qū) 和 To Survivor 區(qū) )和老年代(jdk1.7)。

方法區(qū)/ 永久代 （線程共享）

• 即我們常說的永久代(Permanent Generation), 用于存儲(chǔ)被 JVM 加載的類信息、常量、靜態(tài)變量、即時(shí)編譯器編譯后的代碼等數(shù)據(jù). HotSpot VM把GC分代收集擴(kuò)展至方法區(qū), 即使用Java堆的永久代來實(shí)現(xiàn)方法區(qū), 這樣 HotSpot 的垃圾收集器就可以像管理 Java 堆一樣管理這部分內(nèi)存,而不必為方法區(qū)開發(fā)專門的內(nèi)存管理器(永久帶的內(nèi)存回收的主要目標(biāo)是針對(duì)常量池的回收和類型的卸載, 因此收益一般很小)。

運(yùn)行時(shí)常量池

• （Runtime Constant Pool）是方法區(qū)的一部分。Class 文件中除了有類的版本、字段、方法、接口等描述等信息外，還有一項(xiàng)信息是常量池（Constant Pool Table），用于存放編譯期生成的各種字面量和符號(hào)引用，這部分內(nèi)容將在類加載后存放到方法區(qū)的運(yùn)行時(shí)常量池中。Java 虛擬機(jī)對(duì) Class 文件的每一部分（自然也包括常量池）的格式都有嚴(yán)格的規(guī)定，每一個(gè)字節(jié)用于存儲(chǔ)哪種數(shù)據(jù)都必須符合規(guī)范上的要求，這樣才會(huì)被虛擬機(jī)認(rèn)可、裝載和執(zhí)行。

直接內(nèi)存

• 直接內(nèi)存并不是 JVM 運(yùn)行時(shí)數(shù)據(jù)區(qū)的一部分, 但也會(huì)被頻繁的使用: 在 JDK 1.4 引入的 NIO 提供了基于 Channel 與 Buffer 的 IO 方式, 它可以使用 Native 函數(shù)庫直接分配堆外內(nèi)存, 然后使用DirectByteBuffer 對(duì)象作為這塊內(nèi)存的引用進(jìn)行操作， 這樣就避免了在 Java堆和 Native 堆中來回復(fù)制數(shù)據(jù), 因此在一些場(chǎng)景中可以顯著提高性能。

JVM運(yùn)行時(shí)內(nèi)存(jdk1.7)

• Java 堆從 GC 的角度還可以細(xì)分為: 新生代( Eden 區(qū) 、 From Survivor 區(qū) 和 To Survivor 區(qū) )和老年代
  

  

新生代

是用來存放新生的對(duì)象。一般占據(jù)堆的1/3空間。由于頻繁創(chuàng)建對(duì)象，所以新生代會(huì)頻繁觸發(fā)MinorGC 進(jìn)行垃圾回收。新生代又分為 Eden 區(qū)、ServivorFrom、ServivorTo 三個(gè)區(qū)。

• Eden區(qū)：Java新對(duì)象的出生地（如果新創(chuàng)建的對(duì)象占用內(nèi)存很大，則直接分配到老年代）。當(dāng)Eden區(qū)內(nèi)存不夠的時(shí)候就會(huì)觸發(fā)MinorGC，對(duì)新生代區(qū)進(jìn)行一次垃圾回收。

• ServivorFrom：上一次 GC 的幸存者，作為這一次 GC 的被掃描者。

• ServivorTo：保留了一次 MinorGC 過程中的幸存者。

• MinorGC 的過程：（復(fù)制->清空->互換）MinorGC 采用復(fù)制算法。

• eden 、 servicorFrom  復(fù)制到 ServicorTo，年齡+1
      首先，把 Eden和 ServivorFrom區(qū)域中存活的對(duì)象復(fù)制到 ServicorTo區(qū)域（如果有對(duì)象的年齡以及達(dá)到了老年的(默認(rèn)15歲，可以通過-XXMaxTenuringThreshold設(shè)置)，則賦值到老年代區(qū)），同時(shí)把這些對(duì)象的年齡+1（如果 ServicorTo 不夠位置了就放到老年區(qū)）。

• 清空 eden 、 servicorFrom**
     清空 Eden 和 ServicorFrom 中的對(duì)象；

• ServicorTo 和 ServicorFrom 互換
     最后，ServicorTo 和 ServicorFrom 互換，原 ServicorTo 成為下一次 GC 時(shí)的 ServicorFrom區(qū)。

老年代

• 主要存放應(yīng)用程序中生命周期長(zhǎng)的內(nèi)存對(duì)象。

• 老年代的對(duì)象比較穩(wěn)定，所以 MajorGC 不會(huì)頻繁執(zhí)行。在進(jìn)行 MajorGC 前一般都先進(jìn)行了一次 MinorGC，使得有新生代的對(duì)象晉身入老年代，導(dǎo)致空間不夠用時(shí)才觸發(fā)。當(dāng)無法找到足夠大的連續(xù)空間分配給新創(chuàng)建的較大對(duì)象時(shí)也會(huì)提前觸發(fā)一次 MajorGC 進(jìn)行垃圾回收騰出空間。

• MajorGC 采用標(biāo)記清除算法：首先掃描一次所有老年代，標(biāo)記出存活的對(duì)象，然后回收沒有標(biāo)記的對(duì)象。MajorGC 的耗時(shí)比較長(zhǎng)，因?yàn)橐獟呙柙倩厥?。MajorGC 會(huì)產(chǎn)生內(nèi)存碎片，為了減少內(nèi)存損耗，我們一般需要進(jìn)行合并或者標(biāo)記出來方便下次直接分配。當(dāng)老年代也滿了裝不下的時(shí)候，就會(huì)拋出 OOM（Out of Memory）異常。

永久代

-指內(nèi)存的永久保存區(qū)域，主要存放 Class 和 Meta（元數(shù)據(jù)）的信息,Class 在被加載的時(shí)候被放入永久區(qū)域，它和和存放實(shí)例的區(qū)域不同,GC 不會(huì)在主程序運(yùn)行期對(duì)永久區(qū)域進(jìn)行清理。所以這也導(dǎo)致了永久代的區(qū)域會(huì)隨著加載的 Class 的增多而脹滿，最終拋出 OOM 異常。

JAVA8 與元數(shù)據(jù)

在Java8中，永久代已經(jīng)被移除，被一個(gè)稱為“元數(shù)據(jù)區(qū)”（元空間）的區(qū)域所取代。元空間的本質(zhì)和永久代類似，元空間與永久代之間最大的區(qū)別在于：元空間并不在虛擬機(jī)中，而是使用本地內(nèi)存。因此，默認(rèn)情況下，元空間的大小僅受本地內(nèi)存限制。類的元數(shù)據(jù)放入 nativememory, 字符串池和類的靜態(tài)變量放入 java 堆中，這樣可以加載多少類的元數(shù)據(jù)就不再由MaxPermSize 控制, 而由系統(tǒng)的實(shí)際可用空間來控制。

垃圾回收與算法

如何確定垃圾

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

• 在 Java 中，引用和對(duì)象是有關(guān)聯(lián)的。如果要操作對(duì)象則必須用引用進(jìn)行。因此，很顯然一個(gè)簡(jiǎn)單的辦法是通過引用計(jì)數(shù)來判斷一個(gè)對(duì)象是否可以回收。簡(jiǎn)單說，即一個(gè)對(duì)象如果沒有任何與之關(guān)聯(lián)的引用，即他們的引用計(jì)數(shù)都不為 0，則說明對(duì)象不太可能再被用到，那么這個(gè)對(duì)象就是可回收對(duì)象。

可達(dá)性分析

• 為了解決引用計(jì)數(shù)法的循環(huán)引用問題，Java 使用了可達(dá)性分析的方法。通過一系列的“GC roots”對(duì)象作為起點(diǎn)搜索。如果在“GC roots”和一個(gè)對(duì)象之間沒有可達(dá)路徑，則稱該對(duì)象是不可達(dá)的。要注意的是，不可達(dá)對(duì)象不等價(jià)于可回收對(duì)象，不可達(dá)對(duì)象變?yōu)榭苫厥諏?duì)象至少要經(jīng)過兩次標(biāo)記過程。兩次標(biāo)記后仍然是可回收對(duì)象，則將面臨回收。

標(biāo)記清除算法（ Mark-Sweep ）

24. 最基礎(chǔ)的垃圾回收算法，分為兩個(gè)階段，標(biāo)注和清除。標(biāo)記階段標(biāo)記出所有需要回收的對(duì)象，清除階段回收被標(biāo)記的對(duì)象所占用的空間。如圖
    

    

    
    從圖中我們就可以發(fā)現(xiàn)，該算法最大的問題是內(nèi)存碎片化嚴(yán)重，后續(xù)可能發(fā)生大對(duì)象不能找到可利用空間的問題。

復(fù)制算法（copying ）

• 為了解決 Mark-Sweep 算法內(nèi)存碎片化的缺陷而被提出的算法。按內(nèi)存容量將內(nèi)存劃分為等大小的兩塊。每次只使用其中一塊，當(dāng)這一塊內(nèi)存滿后將尚存活的對(duì)象復(fù)制到另一塊上去，把已使用的內(nèi)存清掉，如圖：
  

  

  
  這種算法雖然實(shí)現(xiàn)簡(jiǎn)單，內(nèi)存效率高，不易產(chǎn)生碎片，但是最大的問題是可用內(nèi)存被壓縮到了原本的一半。且存活對(duì)象增多的話，Copying 算法的效率會(huì)大大降低。

標(biāo)記整理算法(Mark-Compact)

結(jié)合了以上兩個(gè)算法，為了避免缺陷而提出。標(biāo)記階段和 Mark-Sweep 算法相同，標(biāo)記后不是清理對(duì)象，而是將存活對(duì)象移向內(nèi)存的一端。然后清除端邊界外的對(duì)象。如圖：

分代收集算法

• 分代收集法是目前大部分 JVM 所采用的方法，其核心思想是根據(jù)對(duì)象存活的不同生命周期將內(nèi)存劃分為不同的域，一般情況下將 GC 堆劃分為老生代(Tenured/Old Generation)和新生(YoungGeneration)。老生代的特點(diǎn)是每次垃圾回收時(shí)只有少量對(duì)象需要被回收，新生代的特點(diǎn)是每次垃圾回收時(shí)都有大量垃圾需要被回收，因此可以根據(jù)不同區(qū)域選擇不同的算法。

新生代與復(fù)制算法

• 目前大部分 JVM 的 GC 對(duì)于新生代都采取 Copying 算法，因?yàn)樾律忻看卫厥斩家厥沾蟛糠謱?duì)象，即要復(fù)制的操作比較少，但通常并不是按照 1：1 來劃分新生代。一般將新生代劃分為一塊較大的 Eden 空間和兩個(gè)較小的 Survivor 空間(From Space, To Space)，每次使用Eden 空間和其中的一塊 Survivor 空間，當(dāng)進(jìn)行回收時(shí)，將該兩塊空間中還存活的對(duì)象復(fù)制到另一塊 Survivor 空間中。
  

  

老年代與標(biāo)記復(fù)制算法

而老年代因?yàn)槊看沃换厥丈倭繉?duì)象，因而采用 Mark-Compact 算法。

• JAVA 虛擬機(jī)提到過的處于方法區(qū)的永生代(Permanet Generation)，它用來存儲(chǔ) class 類，常量，方法描述等。對(duì)永生代的回收主要包括廢棄常量和無用的類。

• 對(duì)象的內(nèi)存分配主要在新生代的 Eden Space 和 Survivor Space 的 From Space(Survivor 目前存放對(duì)象的那一塊)，少數(shù)情況會(huì)直接分配到老生代。

• 當(dāng)新生代的 Eden Space 和 From Space 空間不足時(shí)就會(huì)發(fā)生一次 GC，進(jìn)行 GC 后，EdenSpace 和 From Space 區(qū)的存活對(duì)象會(huì)被挪到 To Space，然后將 Eden Space 和 FromSpace 進(jìn)行清理。

• 如果 To Space 無法足夠存儲(chǔ)某個(gè)對(duì)象，則將這個(gè)對(duì)象存儲(chǔ)到老生代。

• 在進(jìn)行 GC 后，使用的便是 Eden Space 和 To Space 了，如此反復(fù)循環(huán)。

• 當(dāng)對(duì)象在 Survivor 區(qū)躲過一次 GC 后，其年齡就會(huì)+1。默認(rèn)情況下年齡到達(dá) 15 的對(duì)象會(huì)被移到老生代中。

GC  分代收集算法 VS  分區(qū)收集算法

分代收集算法

當(dāng)前主流 JVM 垃圾收集都采用”分代收集”(Generational Collection)算法, 這種算法會(huì)根據(jù)對(duì)象存活周期的不同將內(nèi)存劃分為幾塊, 如 JVM 中的 新生代、老年代、永久代，這樣就可以根據(jù)各年代特點(diǎn)分別采用最適當(dāng)?shù)?GC 算法。

• 在新生代-復(fù)制算法      
  每次垃圾收集都能發(fā)現(xiàn)大批對(duì)象已死, 只有少量存活. 因此選用復(fù)制算法, 只需要付出少量存活對(duì)象的復(fù)制成本就可以完成收集。

• 在老年代-標(biāo)記整理算法
  因?yàn)閷?duì)象存活率高、沒有額外空間對(duì)它進(jìn)行分配擔(dān)保, 就必須采用“標(biāo)記—清理”或“標(biāo)記—整理”算法來進(jìn)行回收, 不必進(jìn)行內(nèi)存復(fù)制, 且直接騰出空閑內(nèi)存。

分區(qū)收集算法

分區(qū)算法則將整個(gè)堆空間劃分為連續(xù)的不同小區(qū)間, 每個(gè)小區(qū)間獨(dú)立使用, 獨(dú)立回收. 這樣做的好處是可以控制一次回收多少個(gè)小區(qū)間 , 根據(jù)目標(biāo)停頓時(shí)間, 每次合理地回收若干個(gè)小區(qū)間(而不是整個(gè)堆), 從而減少一次 GC 所產(chǎn)生的停頓。

GC 垃圾收集器

Java 堆內(nèi)存被劃分為新生代和年老代兩部分，新生代主要使用復(fù)制和標(biāo)記-清除垃圾回收 算法 ,年老代主要使用標(biāo)記-整理垃圾回收算法，因此 java 虛擬中針對(duì)新生代和年老代分別提供了多種不同的垃圾收集器，JDK1.6 中 Sun HotSpot 虛擬機(jī)的垃圾收集器如下：

Serial  垃圾收集器 （單線程、 復(fù)制算法 ）

• Serial（英文連續(xù)）是最基本垃圾收集器，使用復(fù)制算法，曾經(jīng)是JDK1.3.1之前新生代唯一的垃圾收集器。Serial 是一個(gè)單線程的收集器，它不但只會(huì)使用一個(gè) CPU 或一條線程去完成垃圾收集工作，并且在進(jìn)行垃圾收集的同時(shí)，必須暫停其他所有的工作線程，直到垃圾收集結(jié)束。Serial 垃圾收集器雖然在收集垃圾過程中需要暫停所有其他的工作線程，但是它簡(jiǎn)單高效，對(duì)于限定單個(gè) CPU 環(huán)境來說，沒有線程交互的開銷，可以獲得最高的單線程垃圾收集效率，因此 Serial垃圾收集器依然是 java 虛擬機(jī)運(yùn)行在 Client 模式下默認(rèn)的新生代垃圾收集器。

ParNew  垃圾收集器 （Serial+ 多線程 ）

• ParNew 垃圾收集器其實(shí)是 Serial 收集器的多線程版本，也使用復(fù)制算法，除了使用多線程進(jìn)行垃圾收集之外，其余的行為和 Serial 收集器完全一樣，ParNew 垃圾收集器在垃圾收集過程中同樣也要暫停所有其他的工作線程。ParNew 收集器默認(rèn)開啟和 CPU 數(shù)目相同的線程數(shù)，可以通過-XX:ParallelGCThreads 參數(shù)來限制垃圾收集器的線程數(shù)。【Parallel：平行的】ParNew雖然是除了多線程外和Serial收集器幾乎完全一樣，但是ParNew垃圾收集器是很多java虛擬機(jī)運(yùn)行在 Server 模式下新生代的默認(rèn)垃圾收集器。

Parallel Scavenge  收集器 （多線程復(fù)制算法、高效）

• Parallel Scavenge 收集器也是一個(gè)新生代垃圾收集器，同樣使用復(fù)制算法，也是一個(gè)多線程的垃圾收集器，它重點(diǎn)關(guān)注的是程序達(dá)到一個(gè)可控制的吞吐量（Thoughput，CPU 用于運(yùn)行用戶代碼的時(shí)間/CPU 總消耗時(shí)間，即吞吐量=運(yùn)行用戶代碼時(shí)間/(運(yùn)行用戶代碼時(shí)間+垃圾收集時(shí)間)），高吞吐量可以最高效率地利用 CPU 時(shí)間，盡快地完成程序的運(yùn)算任務(wù)，主要適用于在后臺(tái)運(yùn)算而不需要太多交互的任務(wù)。自適應(yīng)調(diào)節(jié)策略也是 ParallelScavenge 收集器與 ParNew 收集器的一個(gè)重要區(qū)別。

Serial Old  收集器 (單線程標(biāo)記整理算法）

Serial Old 是 Serial 垃圾收集器年老代版本，它同樣是個(gè)單線程的收集器，使用標(biāo)記-整理算法，這個(gè)收集器也主要是運(yùn)行在 Client 默認(rèn)的 java 虛擬機(jī)默認(rèn)的年老代垃圾收集器。在 Server 模式下，主要有兩個(gè)用途：
   1. 在 JDK1.5 之前版本中與新生代的 Parallel Scavenge 收集器搭配使用。
   2. 作為年老代中使用 CMS 收集器的后備垃圾收集方案。
新生代 Serial 與年老代 Serial Old 搭配垃圾收集過程圖：

Parallel Old  收集器（多線程標(biāo)記整理算法）

Parallel Old收集器是Parallel Scavenge的年老代版本，使用多線程的標(biāo)記-整理算法，在JDK1.6才開始提供。在 JDK1.6 之前，新生代使用 ParallelScavenge 收集器只能搭配年老代的 Serial Old 收集器，只能保證新生代的吞吐量?jī)?yōu)先，無法保證整體的吞吐量，Parallel Old 正是為了在年老代同樣提供吞吐量?jī)?yōu)先的垃圾收集器，如果系統(tǒng)對(duì)吞吐量要求比較高，可以優(yōu)先考慮新生代 Parallel Scavenge和年老代 Parallel Old 收集器的搭配策略。新生代 Parallel Scavenge 和年老代 Parallel Old 收集器搭配運(yùn)行過程圖：

CMS  收集器 （多線程標(biāo)記清除算法）

Concurrent mark sweep(CMS)收集器是一種年老代垃圾收集器，其最主要目標(biāo)是獲取最短垃圾回收停頓時(shí)間，和其他年老代使用標(biāo)記-整理算法不同，它使用多線程的標(biāo)記-清除算法。最短的垃圾收集停頓時(shí)間可以為交互比較高的程序提高用戶體驗(yàn)。CMS 工作機(jī)制相比其他的垃圾收集器來說更復(fù)雜，整個(gè)過程分為以下 4 個(gè)階段：
 1.初始標(biāo)記：只是標(biāo)記一下 GC Roots 能直接關(guān)聯(lián)的對(duì)象，速度很快，仍然需要暫停所有的工作線程。
 2.并發(fā)標(biāo)記： 進(jìn)行 GC Roots 跟蹤的過程，和用戶線程一起工作，不需要暫停工作線程。
 3.重新標(biāo)記： 為了修正在并發(fā)標(biāo)記期間，因用戶程序繼續(xù)運(yùn)行而導(dǎo)致標(biāo)記產(chǎn)生變動(dòng)的那一部分對(duì)象的標(biāo)記記錄，仍然需要暫停所有的工作線程。
 4.并發(fā)清除： 清除 GC Roots 不可達(dá)對(duì)象，和用戶線程一起工作，不需要暫停工作線程。由于耗時(shí)最長(zhǎng)的并
發(fā)標(biāo)記和并發(fā)清除過程中，垃圾收集線程可以和用戶現(xiàn)在一起并發(fā)工作，所以總體上來看CMS 收集器的內(nèi)存回收和用戶線程是一起并發(fā)地執(zhí)行。

G1  收集器

Garbage first 垃圾收集器是目前垃圾收集器理論發(fā)展的最前沿成果，相比與 CMS 收集器，G1 收
集器兩個(gè)最突出的改進(jìn)是：

1. 基于標(biāo)記-整理算法，不產(chǎn)生內(nèi)存碎片。

2. 可以非常精確控制停頓時(shí)間，在不犧牲吞吐量前提下，實(shí)現(xiàn)低停頓垃圾回收。
   G1 收集器避免全區(qū)域垃圾收集，它把堆內(nèi)存劃分為大小固定的幾個(gè)獨(dú)立區(qū)域，并且跟蹤這些區(qū)域的垃圾收集進(jìn)度，同時(shí)在后臺(tái)維護(hù)一個(gè)優(yōu)先級(jí)列表，每次根據(jù)所允許的收集時(shí)間，優(yōu)先回收垃圾最多的區(qū)域。區(qū)域劃分和優(yōu)先級(jí)區(qū)域回收機(jī)制，確保 G1 收集器可以在有限時(shí)間獲得最高的垃圾收集效率。