談垃圾回收器之前,要先講講垃圾回收算法,以及JVM對垃圾的認(rèn)定策略,JVM垃圾回收器是垃圾回收算法的具體實現(xiàn),了解了前面的前置知識,有利于對垃圾回收器的理解。

什么是垃圾?

垃圾,主要是指堆上的對象,那么如何確定這些對象是可以被回收的呢?

大概思路就是,如果一個對象永遠(yuǎn)不可能被訪問到,那么就是垃圾,可以被回收了如何確定對象永遠(yuǎn)不會被使用呢?

引用計數(shù)法

在對象中添加一個引用計數(shù)器，每當(dāng)有一個地方引用它時，計數(shù)器值就加一；當(dāng)引用失效時，計數(shù)器值就減一；任何時刻計數(shù)器為零的對象就是不可能再被使用的。但是，在Java領(lǐng)域，至少主流的Java虛擬機(jī)里面都沒有選用引用計數(shù)算法來管理內(nèi)存，主要原因是，這個看似簡單的算法有很多例外情況要考慮，必須要配合大量額外處理才能保證正確地工作，譬如單純的引用計數(shù)就很難解決對象之間相互循環(huán)引用的問題。

如圖,每一個對象的引用都是1,構(gòu)成了循環(huán)引用,但是并不能被其他對象訪問,這兩個對象再無任何引用，引用計數(shù)算法也就無法回收它們。

代碼驗證:

package com.courage; 
public class ReferenceCountingGC { 
    public Object instance = null; 
    private static final int _1MB = 1024 * 1024; 
    /** 
     * 這個成員屬性的唯一意義就是占點內(nèi)存，以便能在GC日志中看清楚是否有回收過 
     */ 
    private byte[] bigSize = new byte[5* _1MB]; 
    public static void testGC() { 
        //5 M 
        ReferenceCountingGC objA = new ReferenceCountingGC(); 
        //5 M 
        ReferenceCountingGC objB = new ReferenceCountingGC(); 
        objA.instance = objB; 
        objB.instance = objA; 
        objA = null; 
        objB = null; 
// 假設(shè)在這行發(fā)生GC，objA和objB是否能被回收？ 
        System.gc(); 
    } 
    public static void main(String[] args) { 
        testGC(); 
    } 
} 

執(zhí)行結(jié)果:

[0.004s][warning][gc] -XX:+PrintGCDetails is deprecated. Will use -Xlog:gc* instead. 
[0.012s][info   ][gc,heap] Heap region size: 1M 
[0.015s][info   ][gc     ] Using G1 
[0.015s][info   ][gc,heap,coops] Heap address: 0x0000000701000000, size: 4080 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 
...... 
[0.119s][info   ][gc,metaspace   ] GC(0) Metaspace: 805K->805K(1056768K) 
[0.119s][info   ][gc             ] GC(0) Pause Full (System.gc()) 14M->0M(8M) 2.886ms 
[0.119s][info   ][gc,cpu         ] GC(0) User=0.03s Sys=0.00s Real=0.00s 
[0.120s][info   ][gc,heap,exit   ] Heap 
...... 

為了篇幅,我將部分打印內(nèi)容省略了,可見System.gc()后內(nèi)存占用由14M->0M,將對象這10M釋放了。也就是JVM里面并沒使用引用計數(shù)法來標(biāo)記垃圾。

根可達(dá)算法

這個算法的基本思路就是通過一系列稱為“GC Roots”的根對象作為起始節(jié)點集，從這些節(jié)點開始，根據(jù)引用關(guān)系向下搜索，搜索過程所走過的路徑稱為“引用鏈”（Reference Chain），如果某個對象到GC Roots間沒有任何引用鏈相連，或者用圖論的話來說就是從GC Roots到這個對象不可達(dá)時，則證明此對象是不可能再被使用的。

在Java技術(shù)體系里面，固定可作為GC Roots的對象包括以下幾種：

1. 在虛擬機(jī)棧（棧幀中的本地變量表）中引用的對象，譬如各個線程被調(diào)用的方法堆棧中使用到的
   參數(shù)、局部變量、臨時變量等在方法區(qū)中類靜態(tài)屬性引用的對象，譬如Java類的引用類型靜態(tài)變量。
2. 在方法區(qū)中常量引用的對象，譬如字符串常量池（String Table）里的引用。
3. 在本地方法棧中JNI（即通常所說的Native方法）引用的對象。
4. Java虛擬機(jī)內(nèi)部的引用，如基本數(shù)據(jù)類型對應(yīng)的Class對象，一些常駐的異常對象（比如
   NullPointExcepiton、OutOfMemoryError）等，還有系統(tǒng)類加載器。
5. 所有被同步鎖（synchronized關(guān)鍵字）持有的對象。
6. 反映Java虛擬機(jī)內(nèi)部情況的JMXBean、JVMTI中注冊的回調(diào)、本地代碼緩存等。

垃圾回收算法

本文介紹了常見的三種垃圾回收算法（mark-sweep,mark-compact,mark-copy），是java虛擬機(jī)各種垃圾收集器的算法基礎(chǔ)。

垃圾回收算法思想

當(dāng)前商業(yè)虛擬機(jī)的垃圾收集器，大多數(shù)都遵循了“分代收集”（Generational Collection）的理論進(jìn)行設(shè)計，分代收集名為理論，實質(zhì)是一套符合大多數(shù)程序運(yùn)行實際情況的經(jīng)驗法則，它建立在兩個分代假說之上：

1）弱分代假說（Weak Generational Hypothesis）：絕大多數(shù)對象都是朝生夕滅的。

2）強(qiáng)分代假說（Strong Generational Hypothesis）：熬過越多次垃圾收集過程的對象就越難以消亡。

這兩個分代假說共同奠定了多款常用的垃圾收集器的一致的設(shè)計原則：收集器應(yīng)該將Java堆劃分出不同的區(qū)域，然后將回收對象依據(jù)其年齡（年齡即對象熬過垃圾收集過程的次數(shù)）分配到不同的區(qū)域之中存儲顯而易見，如果一個區(qū)域中大多數(shù)對象都是朝生夕滅，難以熬過垃圾收集過程的話，那么把它們集中放在一起，每次回收時只關(guān)注如何保留少量存活而不是去標(biāo)記那些大量將要被回收的對象，就能以較低代價回收到大量的空間；

如果剩下的都是難以消亡的對象，那把它們集中放在一塊，虛擬機(jī)便可以使用較低的頻率來回收這個區(qū)域，這就同時兼顧了垃圾收集的時間開銷和內(nèi)存的空間有效利用。

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

算法分為“標(biāo)記”和“清除”兩個階段：首先標(biāo)記出所有需要回收的對象，在標(biāo)記完成后，統(tǒng)一回收掉所有被標(biāo)記的對象，也可以反過來，標(biāo)記存活的對象，統(tǒng)一回收所有未被標(biāo)記的對象。

它的主要缺點有兩個：

第一個是執(zhí)行效率不穩(wěn)定，如果Java堆中包含大量對象，而且其中大部分是需要被回收的，這時必須進(jìn)行大量標(biāo)記和清除的動作，導(dǎo)致標(biāo)記和清除兩個過程的執(zhí)行效率都隨對象數(shù)量增長而降低；

第二個是內(nèi)存空間的碎片化問題，標(biāo)記、清除之后會產(chǎn)生大量不連續(xù)的內(nèi)存碎片，空間碎片太多可能會導(dǎo)致當(dāng)以后在程序運(yùn)行過程中需要分配較大對象時無法找到足夠的連續(xù)內(nèi)存而不得不提前觸發(fā)另一次垃圾收集動作。

標(biāo)記-復(fù)制 Mark-Copy

標(biāo)記-復(fù)制算法常被簡稱為復(fù)制算法它將可用內(nèi)存按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當(dāng)這一塊的內(nèi)存用完了，就將還存活著的對象復(fù)制到另外一塊上面，然后再把已使用過的內(nèi)存空間一次清理掉。

如果內(nèi)存中多數(shù)對象都是存活的，這種算法將會產(chǎn)生大量的內(nèi)存間復(fù)制的開銷，但對于多數(shù)對象都是可回收的情況，算法需要復(fù)制的就是占少數(shù)的存活對象，而且每次都是針對整個半?yún)^(qū)進(jìn)行內(nèi)存回收，分配內(nèi)存時也就不用考慮有空間碎片的復(fù)雜情況，只要移動堆頂指針，按順序分配即可。這樣實現(xiàn)簡單，運(yùn)行高效，不過其缺陷也顯而易見，這種復(fù)制回收算法的代價是將可用內(nèi)存縮小為了原來的一半，空間浪費(fèi)未免太多了。

標(biāo)記-壓縮 Mark-Compact

標(biāo)記-復(fù)制算法在對象存活率較高時就要進(jìn)行較多的復(fù)制操作，效率將會降低。更關(guān)鍵的是，如果不想浪費(fèi)50%的空間，就需要有額外的空間進(jìn)行分配擔(dān)保，以應(yīng)對被使用的內(nèi)存中所有對象都100%存活的極端情況，所以在老年代一般不能直接選用這種算法。

標(biāo)記-壓縮算法其中的標(biāo)記過程仍然與“標(biāo)記-清除”算法一樣，但后續(xù)步驟不是直接對可回收對象進(jìn)行清理，而是讓所有存活的對象都向內(nèi)存空間一端移動，然后直接清理掉邊界以外的內(nèi)存:

標(biāo)記-清除算法與標(biāo)記-整理算法的本質(zhì)差異在于前者是一種非移動式的回收算法，而后者是移動式的。是否移動回收后的存活對象是一項優(yōu)缺點并存的風(fēng)險決策：如果移動存活對象，尤其是在老年代這種每次回收都有大量對象存活區(qū)域，移動存活對象并更新所有引用這些對象的地方將會是一種極為負(fù)重的操作，而且這種對象移動操作必須全程暫停用戶應(yīng)用程序(STW問題)才能進(jìn)行 。

垃圾處理器

基于上面的三種垃圾回收算法,衍生出7種垃圾回收器:

Serial收集器

這個收集器是一個單線程工作的收集器，但它的“單線程”的意義并不僅僅是說明它只會使用一個處理器或一條收集線程去完成垃圾收集工作，更重要的是強(qiáng)調(diào)在它進(jìn)行垃圾收集時，必須暫停其他所有工作線程，直到它收集結(jié)束。

迄今為止，它依然是HotSpot虛擬機(jī)運(yùn)行在客戶端模式下的默認(rèn)新生代收集器，有著優(yōu)于其他收集器的地方，那就是簡單而高效（與其他收集器的單線程相比），對于內(nèi)存資源受限的環(huán)境，它是所有收集器里額外內(nèi)存消耗（Memory Footprint） [1] 最小的；對于單核處理器或處理器核心數(shù)較少的環(huán)境來說，Serial收集器由于沒有線程交互的開銷，專心做垃圾收集自然可以獲得最高的單線程收集效率。Serial收集器對于運(yùn)行在客戶端模式下的虛擬機(jī)來說是一個很好的選擇。

ParNew收集器

ParNew收集器實質(zhì)上是Serial收集器的多線程并行版本，除了同時使用多條線程進(jìn)行垃圾收集之

外，其余的行為包括Serial收集器可用的所有控制參數(shù)（例如：-XX：SurvivorRatio、-XX：

PretenureSizeThreshold、-XX：HandlePromotionFailure等）、收集算法、Stop The World、對象分配規(guī)

則、回收策略等都與Serial收集器完全一致，在實現(xiàn)上這兩種收集器也共用了相當(dāng)多的代碼。

ParNew收集器除了支持多線程并行收集之外，其他與Serial收集器相比并沒有太多創(chuàng)新之處，但它

卻是不少運(yùn)行在服務(wù)端模式下的HotSpot虛擬機(jī)，尤其是JDK 7之前的遺留系統(tǒng)中首選的新生代收集

ParNew收集器在單核心處理器的環(huán)境中絕對不會有比Serial收集器更好的效果，甚至由于存在線程

交互的開銷，該收集器在通過超線程（Hyper-Threading）技術(shù)實現(xiàn)的偽雙核處理器環(huán)境中都不能百分之百保證超越Serial收集器。當(dāng)然，隨著可以被使用的處理器核心數(shù)量的增加，ParNew對于垃圾收集時

系統(tǒng)資源的高效利用還是很有好處的。

Parallel Scavenge收集器

Parallel Scavenge收集器也是一款新生代收集器，它同樣是基于標(biāo)記-復(fù)制算法實現(xiàn)的收集器，也是能夠并行收集的多線程收集器……Parallel Scavenge的諸多特性從表面上看和ParNew非常相似，那它有什么特別之處呢？

Parallel Scavenge收集器的特點是它的關(guān)注點與其他收集器不同，CMS等收集器的關(guān)注點是盡可能地縮短垃圾收集時用戶線程的停頓時間，而Parallel Scavenge收集器的目標(biāo)則是達(dá)到一個可控制的吞吐量（Throughput）。所謂吞吐量就是處理器用于運(yùn)行用戶代碼的時間與處理器總消耗時間的比值，即：

如果虛擬機(jī)完成某個任務(wù)，用戶代碼加上垃圾收集總共耗費(fèi)了100分鐘，其中垃圾收集花掉1分鐘，那吞吐量就是99%。停頓時間越短就越適合需要與用戶交互或需要保證服務(wù)響應(yīng)質(zhì)量的程序，良好的響應(yīng)速度能提升用戶體驗；而高吞吐量則可以最高效率地利用處理器資源，盡快完成程序的運(yùn)算任務(wù)，主要適合在后臺運(yùn)算而不需要太多交互的分析任務(wù)。

由于與吞吐量關(guān)系密切，Parallel Scavenge收集器也經(jīng)常被稱作“吞吐量優(yōu)先收集器”。

Serial Old收集器

Serial Old是Serial收集器的老年代版本，它同樣是一個單線程收集器，使用標(biāo)記-整理算法。這個收集器的主要意義也是供客戶端模式下的HotSpot虛擬機(jī)使用。如果在服務(wù)端模式下，它也可能有兩種用途：一種是在JDK 5以及之前的版本中與Parallel Scavenge收集器搭配使用，另外一種就是作為CMS收集器發(fā)生失敗時的后備預(yù)案，在并發(fā)收集發(fā)生Concurrent Mode Failure時使用。

Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，支持多線程并發(fā)收集，基于標(biāo)記-整理算法實現(xiàn)。這個收集器是直到JDK 6時才開始提供的，在此之前，新生代的Parallel Scavenge收集器一直處于相當(dāng)尷尬的狀態(tài)，原因是如果新生代選擇了Parallel Scavenge收集器，老年代除了Serial Old（PSMarkSweep）收集器以外別無選擇，其他表現(xiàn)良好的老年代收集器，如CMS無法與它配合工作。

由于老年代Serial Old收集器在服務(wù)端應(yīng)用性能上的“拖累”，使用Parallel Scavenge收集器也未必能在整體上獲得吞吐量最大化的效果。

同樣，由于單線程的老年代收集中無法充分利用服務(wù)器多處理器的并行處理能力，在老年代內(nèi)存空間很大而且硬件規(guī)格比較高級的運(yùn)行環(huán)境中，這種組合的總吞吐量甚至不一定比ParNew加CMS的組合來得優(yōu)秀。直到Parallel Old收集器出現(xiàn)后，“吞吐量優(yōu)先”收集器終于有了比較名副其實的搭配組合，在注重吞吐量或者處理器資源較為稀缺的場合，都可以優(yōu)先考慮Parallel Scavenge加Parallel Old收集器這個組合。

CMS收集器

CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間為目標(biāo)的收集器。目前很大一部分的Java應(yīng)用集中在互聯(lián)網(wǎng)網(wǎng)站或者基于瀏覽器的B/S系統(tǒng)的服務(wù)端上，這類應(yīng)用通常都會較為關(guān)注服務(wù)的響應(yīng)速度，希望系統(tǒng)停頓時間盡可能短，以給用戶帶來良好的交互體驗。CMS收集器就非常符合這類應(yīng)用的需求。

從名字（包含“Mark Sweep”）上就可以看出CMS收集器是基于標(biāo)記-清除算法實現(xiàn)的，它的運(yùn)作過程相對于前面幾種收集器來說要更復(fù)雜一些，整個過程分為四個步驟，包括：

1）初始標(biāo)記（CMS initial mark）

2）并發(fā)標(biāo)記（CMS concurrent mark）

3）重新標(biāo)記（CMS remark）

4）并發(fā)清除（CMS concurrent sweep）

優(yōu)點：并發(fā)收集、低停頓

缺點：1.對處理器資源非常敏感

​ 2.無法處理“浮動垃圾”（Floating Garbage）

​ 3.空間碎片

Garbage First收集器

Garbage First（簡稱G1）收集器是垃圾收集器技術(shù)發(fā)展歷史上的里程碑式的成果，它開創(chuàng)了收集器面向局部收集的設(shè)計思路和基于Region的內(nèi)存布局形式。G1是一款主要面向服務(wù)端應(yīng)用的垃圾收集器。

在G1收集器出現(xiàn)之前的所有其他收集器，包括CMS在內(nèi)，垃圾收集的目標(biāo)范圍要么是整個新生代（Minor GC），要么就是整個老年代（Major GC），再要么就是整個Java堆（Full GC）。而G1跳出了這個樊籠，它可以面向堆內(nèi)存任何部分來組成回收集（Collection Set，一般簡稱CSet）進(jìn)行回收，衡量標(biāo)準(zhǔn)不再是它屬于哪個分代，而是哪塊內(nèi)存中存放的垃圾數(shù)量最多，回收收益最大，這就是G1收集器的Mixed GC模式。G1開創(chuàng)的基于Region的堆內(nèi)存布局是它能夠?qū)崿F(xiàn)這個目標(biāo)的關(guān)鍵。雖然G1也仍是遵循分代收集理論設(shè)計的，但其堆內(nèi)存的布局與其他收集器有非常明顯的差異：G1不再堅持固定大小以及固定數(shù)量的分代區(qū)域劃分，而是把連續(xù)的Java堆劃分為多個大小相等的獨(dú)立區(qū)域（Region），每一個Region都可以根據(jù)需要，扮演新生代的Eden空間、Survivor空間，或者老年代空間。收集器能夠?qū)Π缪莶煌巧腞egion采用不同的策略去處理，這樣無論是新創(chuàng)建的對象還是已經(jīng)存活了一段時間、熬過多次收集的舊對象都能獲取很好的收集效果。

Region中還有一類特殊的Humongous區(qū)域，專門用來存儲大對象。G1認(rèn)為只要大小超過了一個Region容量一半的對象即可判定為大對象。每個Region的大小可以通過參數(shù)-XX：G1HeapRegionSize設(shè)定，取值范圍為1MB～32MB，且應(yīng)為2的N次冪。而對于那些超過了整個Region容量的超級大對象，將會被存放在N個連續(xù)的Humongous Region之中，G1的大多數(shù)行為都把Humongous Region作為老年代的一部分來進(jìn)行看待，如圖3-12所示。

雖然G1仍然保留新生代和老年代的概念，但新生代和老年代不再是固定的了，它們都是一系列區(qū)域（不需要連續(xù)）的動態(tài)集合。G1收集器之所以能建立可預(yù)測的停頓時間模型，是因為它將Region作為單次回收的最小單元，即每次收集到的內(nèi)存空間都是Region大小的整數(shù)倍，這樣可以有計劃地避免在整個Java堆中進(jìn)行全區(qū)域的垃圾收集。更具體的處理思路是讓G1收集器去跟蹤各個Region里面的垃圾堆積的“價值”大小，價值即回收所獲得的空間大小以及回收所需時間的經(jīng)驗值，然后在后臺維護(hù)一個優(yōu)先級列表，每次根據(jù)用戶設(shè)定允許的收集停頓時間（使用參數(shù)-XX：MaxGCPauseMillis指定，默認(rèn)值是200毫秒），優(yōu)先處理回收價值收益最大的那些Region，這也就是“Garbage First”名字的由來。這種使用Region劃分內(nèi)存空間，以及具有優(yōu)先級的區(qū)域回收方式，保證了G1收集器在有限的時間內(nèi)獲取盡可能高的收集效率。

垃圾處理器總結(jié)

目前是新生代老年代垃圾回收器組合方式: