2019獨角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

GC引入

在Java的運行時數(shù)據(jù)區(qū)中，程序計數(shù)器、虛擬機棧、本地方法棧三個區(qū)域都是線程私有的，隨線程而生，隨線程而滅，在方法結(jié)束或線程結(jié)束時，內(nèi)存自然就跟著回收了，不需要過多考慮回收的問題。而Java堆和方法區(qū)則不一樣，一個接口中的多個實現(xiàn)類需要的內(nèi)存可能不一樣，一個方法中的多個分支需要的內(nèi)存也可能不一樣，我們只有在程序處于運行期間才能知道會創(chuàng)建哪些對象，這部分內(nèi)存的分配和回收都是動態(tài)的，垃圾回收器關(guān)注的是這部分內(nèi)存，后續(xù)討論的“內(nèi)存”分配回收也是指這一塊，尤其需要注意。

GC主要回答了以下三個問題：

• 哪些內(nèi)存需要回收？
• 什么時候回收？
• 如何回收？

對象存活判定算法

在堆里存放著Java世界中幾乎所有的對象實例，垃圾收集器在對堆進行回收前，首要的就是確定這些對象中哪些還“存活”著，哪些已經(jīng)“死去”（即不可能再被任何途徑使用的對象）。

引用計數(shù)算法

引用計數(shù)算法是在JVM中被摒棄的一種對象存活判定算法，不過它也有一些知名的應(yīng)用場景（如Python、FlashPlayer），因此在這里也簡單介紹一下。

用引用計數(shù)器判斷對象是否存活的過程是這樣的：給對象中添加一個引用計數(shù)器，每當(dāng)有一個地方引用它時，計數(shù)器加1；當(dāng)引用失效時，計數(shù)器減1；任何時刻計數(shù)器為0的對象就是不可能再被使用的。

引用計數(shù)算法的實現(xiàn)簡單，判定效率也很高，大部分情況下是一個不錯的算法。它沒有被JVM采用的原因是它很難解決對象之間循環(huán)引用的問題。例如以下例子：

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

在上面這段代碼中，對象objA 和對象objB都有字段instance，賦值令objA.instance = objB;、objB.instance = objA;，除此之外，這兩個對象再無引用。如果JVM采用引用計數(shù)算法來管理內(nèi)存，這兩個對象不可能再被訪問，但是他們互相引用著對方，導(dǎo)致它們引用計數(shù)不為0，所以引用計數(shù)器無法通知GC收集器回收它們。

可達性分析算法

在主流商用程序語言的實現(xiàn)中，都是通過可達性分析（tracing GC）來判定對象是否存活的。此算法的基本思路是：通過一系列的稱為“GC Roots”的對象作為起點，從這些節(jié)點向下搜索，搜索所走過的路徑稱為引用鏈（Reference Chain），當(dāng)一個對象到GC Roots沒有任何引用鏈相連（用圖論的話來說，就是GC Roots 到這個對象不可達）時，則證明此對象時不可用的。用下圖來加以說明：

上圖中，對象object 5、object 6、object 7雖然互有關(guān)聯(lián)，但是它們到GC Roots是不可達的，所以它們將會被判定為是可回收的對象。

可以看到，GC Roots在對象圖之外，是特別定義的**“起點”**，不可能被對象圖內(nèi)的對象所引用。

準(zhǔn)確地說，GC Roots其實不是一組對象，而通常是一組特別管理的指向引用類型對象的指針，這些指針是tracing GC的trace的起點。它們不是對象圖里的對象，對象也不可能引用到這些“外部”的指針，這也是tracing GC算法不會出現(xiàn)循環(huán)引用問題的基本保證。因此也容易得出，只有引用類型的變量才被認為是Roots，值類型的變量永遠不被認為是Roots。只有深刻理解引用類型和值類型的內(nèi)存分配和管理的不同，才能知道為什么root只能是引用類型。

在Java中，可作為GC Roots的對象包括以下幾種：

虛擬機棧（棧幀中的局部變量表，Local Variable Table）中引用的對象。

方法區(qū)中類靜態(tài)屬性引用的對象。

方法區(qū)中常量引用的對象。

本地方法棧中JNI（即一般說的Native方法）引用的對象。

可以概括得出，可作為GC Roots的節(jié)點主要在全局性的引用與執(zhí)行上下文。要明確的是，tracing gc必須以當(dāng)前存活的對象集為Roots，因此必須選取確定存活的引用類型對象。GC管理的區(qū)域是Java堆，虛擬機棧、方法區(qū)和本地方法棧不被GC所管理，因此選用這些區(qū)域內(nèi)引用的對象作為GC Roots，是不會被GC所回收的。其中虛擬機棧和本地方法棧都是線程私有的內(nèi)存區(qū)域，只要線程沒有終止，就能確保它們中引用的對象的存活。而方法區(qū)中類靜態(tài)屬性引用的對象是顯然存活的。常量引用的對象在當(dāng)前可能存活，因此，也可能是GC roots的一部分。

兩次標(biāo)記與 finalize()方法

即使在可達性分析算法中不可達的對象，也不是一定會死亡的，它們暫時都處于“緩刑”階段，要真正宣告一個對象“死亡”，至少要經(jīng)歷兩次標(biāo)記過程：

如果對象在進行可達性分析后發(fā)現(xiàn)沒有與 GC Roots相連接的引用鏈，那它將會被第一次標(biāo)記并且進行一次篩選，篩選的條件是此對象是否有必要執(zhí)行**finaliza()**方法。當(dāng)對象沒有覆蓋finaliza()方法，或者finaliza()方法已經(jīng)被虛擬機調(diào)用過，虛擬機將這兩種情況都視為“沒有必要執(zhí)行”。

如果這個對象被判定為有必要執(zhí)行finaliza()方法，那么此對象將會放置在一個叫做 F-Queue 的隊列中，并在稍后由一個虛擬機自動建立的、低優(yōu)先級的Finalizer線程去執(zhí)行它。這里所謂的“執(zhí)行”是指虛擬機會觸發(fā)此方法，但并不承諾會等待它運行結(jié)束，原因是：如果一個對象在finaliza()方法中執(zhí)行緩慢，或者發(fā)生了死循環(huán)（更極端的情況），將很可能導(dǎo)致F-Queue 隊列中的其它對象永久處于等待，甚至導(dǎo)致整個內(nèi)存回收系統(tǒng)崩潰。

finaliza()方法是對象逃脫死亡命運的最后一次機會，稍后GC將對F-Queue 隊列中的對象進行第二次小規(guī)模的標(biāo)記。如果對象想在finaliza()方法中成功拯救自己，只要重新與引用鏈上的任何一個對象建立關(guān)聯(lián)即可，例如把自己（this關(guān)鍵字）賦值給某個類變量或者對象的成員變量，這樣在第二次標(biāo)記時它將被移出“即將回收”的集合；如果對象這時候還沒有逃脫，基本上它就真的被回收了。

需要說明的是，使用finalize()方法來“拯救”對象是不值得提倡的，因為它不是C/C++中的析構(gòu)函數(shù)，而是Java剛誕生時為了使C/C++程序員更容易接受它所做的一個妥協(xié)。它的運行代價高昂，不確定性大，無法保證各個對象的調(diào)用順序。finalize() 能做的工作，使用try-finally或者其它方法都更適合、及時，所以筆者建議大家可以忘掉此方法存在。

回收方法區(qū)

很多人認為方法區(qū)沒有垃圾回收，Java虛擬機規(guī)范中確實說過不要求，而且在方法區(qū)中進行垃圾收集的“性價比”較低：在堆中，尤其是新生代，常規(guī)應(yīng)用進行一次垃圾收集可以回收70%~95%的空間，而方法區(qū)的效率遠低于此。在JDK 1.8中，JVM摒棄了永久代，用元空間來作為方法區(qū)的實現(xiàn)，下面介紹的將是元空間的垃圾回收。

元空間的內(nèi)存管理由元空間虛擬機來完成。先前，對于類的元數(shù)據(jù)我們需要不同的垃圾回收器進行處理，現(xiàn)在只需要執(zhí)行元空間虛擬機的C++代碼即可完成。在元空間中，類和其元數(shù)據(jù)的生命周期和其對應(yīng)的類加載器是相同的。換話句話說，只要類加載器存活，其加載的類的元數(shù)據(jù)也是存活的，因而不會被回收掉。

我們從行文到現(xiàn)在提到的元空間稍微有點不嚴(yán)謹(jǐn)。準(zhǔn)確的來說**，每一個類加載器的存儲區(qū)域都稱作一個元空間，所有的元空間合在一起就是我們一直說的元空間**。當(dāng)一個類加載器被垃圾回收器標(biāo)記為不再存活，其對應(yīng)的元空間會被回收。在元空間的回收過程中沒有重定位和壓縮等操作。但是元空間內(nèi)的元數(shù)據(jù)會進行掃描來確定Java引用。

垃圾收集算法

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

標(biāo)記－清除（Mark-Sweep）算法是最基礎(chǔ)的垃圾收集算法，后續(xù)的收集算法都是基于它的思路并對其不足進行改進而得到的。顧名思義，算法分成“標(biāo)記”、“清除”兩個階段：首先標(biāo)記出所有需要回收的對象，在標(biāo)記完成后統(tǒng)一回收所有被標(biāo)記的對象，標(biāo)記過程在前一節(jié)講述對象標(biāo)記判定時已經(jīng)講過了。

標(biāo)記－清除算法的不足主要有以下兩點：

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

• 效率問題，因為內(nèi)存碎片的存在，操作會變得更加費時，因為查找下一個可用空閑塊已不再是一個簡單操作。

標(biāo)記－清除算法的執(zhí)行過程如下圖所示：

復(fù)制（Copying）算法

為了解決標(biāo)記-清除算法的效率問題，一種稱為“復(fù)制”（Copying）的收集算法出現(xiàn)了，思想為：它將可用內(nèi)存按容量分成大小相等的兩塊，每次只使用其中的一塊。當(dāng)這一塊內(nèi)存用完，就將還存活著的對象復(fù)制到另一塊上面，然后再把已使用過的內(nèi)存空間一次清理掉。

這樣做使得每次都是對整個半?yún)^(qū)進行內(nèi)存回收，內(nèi)存分配時也就不用考慮內(nèi)存碎片等復(fù)雜情況，只要移動堆頂指針，按順序分配內(nèi)存即可，實現(xiàn)簡單，運行高效。只是這種算法的代價是將內(nèi)存縮小為原來的一半，代價可能過高了。復(fù)制算法的執(zhí)行過程如下圖所示：

Minor GC與復(fù)制算法

現(xiàn)在的商業(yè)虛擬機都使用復(fù)制算法來回收新生代。新生代的GC又叫“Minor GC”，IBM公司的專門研究表明：新生代中的對象98%是**“朝生夕死”**的，所以Minor GC非常頻繁，一般回收速度也比較快，同時“朝生夕死”的特性也使得Minor GC使用復(fù)制算法時不需要按照1:1的比例來劃分新生代內(nèi)存空間。

Minor GC過程

事實上，新生代將內(nèi)存分為一塊較大的Eden空間和兩塊較小的Survivor空間（From Survivor和To Survivor），每次Minor GC都使用Eden和From Survivor，當(dāng)回收時，將Eden和From Survivor中還存活著的對象都一次性地復(fù)制到另外一塊To Survivor空間上，最后清理掉Eden和剛使用的Survivor空間。一次Minor GC結(jié)束的時候，Eden空間和From Survivor空間都是空的，而To Survivor空間里面存儲著存活的對象。在下次MinorGC的時候，兩個Survivor空間交換他們的標(biāo)簽，現(xiàn)在是空的“From” Survivor標(biāo)記成為“To”，“To” Survivor標(biāo)記為“From”。因此，在MinorGC結(jié)束的時候，Eden空間是空的，兩個Survivor空間中的一個是空的，而另一個存儲著存活的對象。

HotSpot虛擬機默認的Eden : Survivor的比例是8 : 1，由于一共有兩塊Survivor，所以每次新生代中可用內(nèi)存空間為整個新生代容量的90%（80%＋10%），只有10%的容量會被“浪費”。

分配擔(dān)保

上文說的98%的對象可回收只是一般場景下的數(shù)據(jù)，我們沒有辦法保證每次回收都只有不多于10%的對象存活，當(dāng)Survivor空間不夠用時，需要依賴?yán)夏甏鷥?nèi)存進行分配擔(dān)保（Handle Promotion）。如果另外一塊Survivor上沒有足夠空間存放上一次新生代收集下來的存活對象，這些對象將直接通過分配擔(dān)保機制進入老年代。

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

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

根據(jù)老年代的特點，標(biāo)記－整理（Mark-Compact）算法被提出來，主要思想為：此算法的標(biāo)記過程與標(biāo)記－清除算法一樣，但后續(xù)步驟不是直接對可回收對象進行清理，而是讓所有存活的對象都向一端移動，然后直接清理掉邊界以外的內(nèi)存。具體示意圖如下所示

分代收集（Generational Collection）算法

當(dāng)前商業(yè)虛擬機的垃圾收集都采用分代收集（Generational Collection）算法，此算法相較于前幾種沒有什么新的特征，主要思想為：根據(jù)對象存活周期的不同將內(nèi)存劃分為幾塊，一般是把Java堆分為新生代和老年代，這樣就可以根據(jù)各個年代的特點采用最適合的收集算法：

• 新生代 在新生代中，每次垃圾收集時都發(fā)現(xiàn)有大批對象死去，只有少量存活，那就選用復(fù)制算法，只需要付出少量存活對象的復(fù)制成本就可以完成收集。

• 老年代 在老年代中，因為對象存活率高、沒有額外空間對它進行分配擔(dān)保，就必須使用“標(biāo)記-清除”或“標(biāo)記-整理”算法來進行回收。

HotSpot的算法實現(xiàn)

枚舉根節(jié)點

從可達性分析中從GC Roots節(jié)點找引用鏈這個操作為例，可作為GC Roots的節(jié)點**主要在全局性的引用（例如常量或類靜態(tài)屬性）與執(zhí)行上下文（例如棧幀中的局部變量表）**中，現(xiàn)在很多應(yīng)用僅僅方法區(qū)就有數(shù)百兆，如果要逐個檢查這里面的引用，那么必然會消耗很多時間。

GC停頓（”Stop The World”）

另外，可達性分析工作必須在一個能確保一致性的快照中進行——這里“一致性”的意思是指在整個分析期間整個執(zhí)行系統(tǒng)看起來就像被凍結(jié)在某個時間點上，不可以出現(xiàn)分析過程中對象引用關(guān)系還在不斷變化的情況，這是保證分析結(jié)果準(zhǔn)確性的基礎(chǔ)。這點是導(dǎo)致GC進行時必須停頓所有Java執(zhí)行線程（Sun將這件事情稱為“Stop The World”）的其中一個重要原因，即使是在號稱（幾乎）不會發(fā)生停頓的CMS收集器中，枚舉根節(jié)點時也是必須要停頓的。

準(zhǔn)確式GC與OopMap

由于目前的主流Java虛擬機使用的都是準(zhǔn)確式GC（即使用準(zhǔn)確式內(nèi)存管理，虛擬機知道內(nèi)存中某個位置的數(shù)據(jù)具體是什么類型），所以當(dāng)執(zhí)行系統(tǒng)停頓下來后，并不需要一個不漏地檢查完所有執(zhí)行上下文和全局的引用位置，虛擬機應(yīng)當(dāng)是有辦法直接得知哪些地方存放著對象引用。在HotSpot的實現(xiàn)中，是使用一組稱為OopMap的數(shù)據(jù)結(jié)構(gòu)來達到這個目的的，在類加載完成的時候，HotSpot就把對象內(nèi)什么偏移量上是什么類型的數(shù)據(jù)計算出來，在JIT編譯過程中，也會在特定的位置記錄下棧和寄存器中哪些位置是引用。這樣，GC在掃描時就可以直接得知這些信息了。

安全點（Safepoint）——進行GC時程序停頓的位置

在OopMap的協(xié)助下，HotSpot可以快速且準(zhǔn)確地完成GC Roots枚舉，但一個很現(xiàn)實的問題隨之而來：可能導(dǎo)致引用關(guān)系變化，或者說OopMap內(nèi)容變化的指令非常多，如果為每一條指令都生成對應(yīng)的OopMap，那將會需要大量的額外空間，這樣GC的空間成本將會變得很高。

為此，HotSpot選擇不為每條指令都生成OopMap，而是只在**“特定的位置”記錄這些信息，這些位置便被稱為安全點（Safepoint）。也就是說，程序執(zhí)行時并非在所有地方都能停頓下來開始GC，只有在到達安全點時才能暫停。Safepoint的選定既不能太少以致于讓GC等待時間太長，也不能過于頻繁以致于過分增大運行時的負荷。所以，安全點的選定基本上是以程序“是否具有讓程序長時間執(zhí)行的特征”為標(biāo)準(zhǔn)進行選定的——因為每條指令執(zhí)行的時間都非常短暫，程序不太可能因為指令流長度太長這個原因而過長時間運行，“長時間執(zhí)行”的最明顯特征就是指令序列復(fù)用，例如方法調(diào)用、循環(huán)跳轉(zhuǎn)、異常跳轉(zhuǎn)等**，所以具有這些功能的指令才會產(chǎn)生Safepoint。

對于Sefepoint，另一個需要考慮的問題是如何在GC發(fā)生時讓所有線程（這里不包括執(zhí)行JNI調(diào)用的線程）都“跑”到最近的安全點上再停頓下來。這里有兩種方案可供選擇：

• 搶先式中斷（Preemptive Suspension） 搶先式中斷不需要線程的執(zhí)行代碼主動去配合，在GC發(fā)生時，首先把所有線程全部中斷，如果發(fā)現(xiàn)有線程中斷的地方不在安全點上，就恢復(fù)線程，讓它“跑”到安全點上。現(xiàn)在幾乎沒有虛擬機實現(xiàn)采用搶先式中斷來暫停線程從而響應(yīng)GC事件。

• 主動式中斷（Voluntary Suspension）： 主動式中斷的思想是當(dāng)GC需要中斷線程的時候，不直接對線程操作，僅僅簡單地設(shè)置一個標(biāo)志，各個線程執(zhí)行時主動去輪詢這個標(biāo)志，發(fā)現(xiàn)中斷標(biāo)志為真時就自己中斷掛起。輪詢標(biāo)志的地方和安全點是重合的，另外再加上創(chuàng)建對象需要分配內(nèi)存的地方。

安全區(qū)域（Safe Region）

Safepoint機制保證了程序執(zhí)行時，在不太長的時間內(nèi)就會遇到可進入GC的Safepoint。但是，程序“不執(zhí)行”的時候（如線程處于Sleep狀態(tài)或Blocked狀態(tài)），這時線程無法響應(yīng)JVM的中斷請求，“走到”安全的地方去中斷掛起，這時候就需要安全區(qū)域（Safe Region）來解決。

安全區(qū)域是指在一段代碼片段之中，引用關(guān)系不會發(fā)生變化。在這個區(qū)域中的任意地方開始GC都是安全的。我們也可以把Safe Region看做是被擴展了的Safepoint。

在線程執(zhí)行到Safe Region中的代碼時，首先標(biāo)識自己已經(jīng)進入了Safe Region，那樣，當(dāng)在這段時間里JVM要發(fā)起GC時，就不用管標(biāo)識自己為Safe Region狀態(tài)的線程了。在線程要離開Safe Region時，它要檢查系統(tǒng)是否已經(jīng)完成了根節(jié)點枚舉（或者是整個GC過程），如果完成了，那線程就繼續(xù)執(zhí)行，否則它就必須等待直到收到可以安全離開Safe Region的信號為止。

內(nèi)存分配策略

Java的自動內(nèi)存管理最終可以歸結(jié)為自動化地解決了兩個問題：

• 給對象分配內(nèi)存
• 回收分配給對象的內(nèi)存

對象的內(nèi)存分配通常是在堆上分配（除此以外還有可能經(jīng)過JIT編譯后被拆散為標(biāo)量類型并間接地棧上分配），對象主要分配在新生代的Eden區(qū)上，如果啟動了本地線程分配緩沖，將按線程優(yōu)先在TLAB上分配。少數(shù)情況下也可能會直接分配在老年代中，分配的規(guī)則并不是固定的，實際取決于垃圾收集器的具體組合以及虛擬機中與內(nèi)存相關(guān)的參數(shù)的設(shè)置。

下面以使用Serial/Serial Old收集器為例，介紹內(nèi)存分配的策略。

對象優(yōu)先在Eden區(qū)分配

大多數(shù)情況下，對象在新生代的Eden區(qū)中分配。當(dāng)Eden區(qū)沒有足夠空間進行分配時，虛擬機將發(fā)起一次Minor GC。

大對象直接進入老年代

所謂的大對象是指，需要大量連續(xù)內(nèi)存空間的Java對象，最典型的大對象就是很長的字符串以及數(shù)組。大對象對虛擬機的內(nèi)存分配來說是一個壞消息（尤其是遇到朝生夕滅的“短命大對象”，寫程序時應(yīng)避免），經(jīng)常出現(xiàn)大對象容易導(dǎo)致內(nèi)存還有不少空間時就提前觸發(fā)GC以獲取足夠的連續(xù)空間來安置它們。

虛擬機提供了一個-XX:PretenureSizeThreshold參數(shù)，令大于這個設(shè)置值的對象直接在老年代分配。這樣做的目的是避免在Eden區(qū)及兩個Survivor區(qū)之間發(fā)生大量的內(nèi)存復(fù)制（新生代采用復(fù)制算法回收內(nèi)存）。

長期存活的對象將進入老年代

既然虛擬機采用了分代收集的思想來管理內(nèi)存，那么內(nèi)存回收時就必須能識別哪些對象應(yīng)放在新生代，哪些對象應(yīng)放在老年代中。為了做到這點，虛擬機給每個對象定義了一個對象年齡（Age）計數(shù)器。如果對象在Eden出生并經(jīng)過第一次Minor GC后仍然存活，并且能被Survivor容納的話，將被移動到Survivor空間中，并且對象年齡設(shè)為1。對象在Survivor區(qū)中每“熬過”一次Minor GC，年齡就增加1歲，當(dāng)它的年齡增加到一定程度（默認為15歲），就將會被晉升到老年代中。對象晉升老年代的年齡閾值，可以通過參數(shù)-XX:MaxTenuringThreshold設(shè)置。

動態(tài)對象年齡判定

為了能更好地適應(yīng)不同程序的內(nèi)存狀況，虛擬機并不是永遠地要求對象的年齡必須達到了MaxTenuringThreshold才能晉升老年代，如果在Survivor空間中相同年齡所有對象大小的總和大于Survivor空間的一半，年齡大于或等于該年齡的對象就可以直接進入老年代，無須等到MaxTenuringThreshold中要求的年齡。

空間分配擔(dān)保

在發(fā)生Minor GC之前，虛擬機會先檢查老年代最大可用的連續(xù)空間是否大于新生代所有對象總空間，如果這個條件成立，那么Minor GC可以確保是安全的。如果不成立，則虛擬機會查看HandlePromotionFailure設(shè)置值是否允許擔(dān)保失敗。如果允許，那么會繼續(xù)檢查老年代最大可用的連續(xù)空間是否大于歷次晉升到老年代對象的平均大小，如果大于，將嘗試著進行一次Minor GC，盡管這次Minor GC是有風(fēng)險的；如果小于，或者HandlePromotionFailure設(shè)置不允許冒險，那這時也要改為進行一次Full GC。

前面提到過，新生代使用復(fù)制收集算法，但為了內(nèi)存利用率，只使用其中一個Survivor空間來作為輪換備份,因此當(dāng)出現(xiàn)大量對象在Minor GC后仍然存活的情況（最極端的情況就是內(nèi)存回收后新生代中所有對象都存活），就需要老年代進行分配擔(dān)保，把Survivor無法容納的對象直接進入老年代。與生活中的貸款擔(dān)保類似，老年代要進行這樣的擔(dān)保，前提是老年代本身還有容納這些對象的剩余空間，一共有多少對象會活下來在實際完成內(nèi)存回收之前是無法明確知道的，所以只好取之前每一次回收晉升到老年代對象容量的平均大小值作為經(jīng)驗值，與老年代的剩余空間進行比較，決定是否進行Full GC來讓老年代騰出更多空間。

取平均值進行比較其實仍然是一種動態(tài)概率的手段，也就是說，如果某次Minor GC存活后的對象突增，遠遠高于平均值的話，依然會導(dǎo)致?lián)Ｊ?#xff08;Handle Promotion Failure）。如果出現(xiàn)了HandlePromotionFailure失敗，那就只好在失敗后重新發(fā)起一次Full GC。雖然擔(dān)保失敗時繞的圈子是最大的，但大部分情況下都還是會將HandlePromotionFailure開關(guān)打開，避免Full GC過于頻繁。

Full GC的觸發(fā)條件

對于Minor GC，其觸發(fā)條件非常簡單，當(dāng)Eden區(qū)空間滿時，就將觸發(fā)一次Minor GC。而Full GC則相對復(fù)雜，因此本節(jié)我們主要介紹Full GC的觸發(fā)條件。

調(diào)用System.gc()

此方法的調(diào)用是建議JVM進行Full GC,雖然只是建議而非一定,但很多情況下它會觸發(fā) Full GC,從而增加Full GC的頻率,也即增加了間歇性停頓的次數(shù)。因此強烈建議能不使用此方法就不要使用，讓虛擬機自己去管理它的內(nèi)存，可通過-XX:+ DisableExplicitGC來禁止RMI調(diào)用System.gc()。

老年代空間不足

老年代空間不足的常見場景為前文所講的大對象直接進入老年代、長期存活的對象進入老年代等，當(dāng)執(zhí)行Full GC后空間仍然不足，則拋出如下錯誤： Java.lang.OutOfMemoryError: Java heap space 為避免以上兩種狀況引起的Full GC，調(diào)優(yōu)時應(yīng)盡量做到讓對象在Minor GC階段被回收、讓對象在新生代多存活一段時間及不要創(chuàng)建過大的對象及數(shù)組。

空間分配擔(dān)保失敗

前文介紹過，使用復(fù)制算法的Minor GC需要老年代的內(nèi)存空間作擔(dān)保，如果出現(xiàn)了HandlePromotionFailure擔(dān)保失敗，則會觸發(fā)Full GC。

JDK 1.7及以前的永久代空間不足

在JDK 1.7及以前，HotSpot虛擬機中的方法區(qū)是用永久代實現(xiàn)的，永久代中存放的為一些class的信息、常量、靜態(tài)變量等數(shù)據(jù)，當(dāng)系統(tǒng)中要加載的類、反射的類和調(diào)用的方法較多時，Permanet Generation可能會被占滿，在未配置為采用CMS GC的情況下也會執(zhí)行Full GC。如果經(jīng)過Full GC仍然回收不了，那么JVM會拋出如下錯誤信息： java.lang.OutOfMemoryError: PermGen space 為避免PermGen占滿造成Full GC現(xiàn)象，可采用的方法為增大PermGen空間或轉(zhuǎn)為使用CMS GC。

在JDK 1.8中用元空間替換了永久代作為方法區(qū)的實現(xiàn)，元空間是本地內(nèi)存，因此減少了一種Full GC觸發(fā)的可能性。

Concurrent Mode Failure

執(zhí)行CMS GC的過程中同時有對象要放入老年代，而此時老年代空間不足（有時候“空間不足”是CMS GC時當(dāng)前的浮動垃圾過多導(dǎo)致暫時性的空間不足觸發(fā)Full GC），便會報Concurrent Mode Failure錯誤，并觸發(fā)Full GC。

轉(zhuǎn)載于:https://my.oschina.net/jiansin/blog/2872510

總結(jié)

以上是生活随笔為你收集整理的Java虚拟机-第二篇-GC算法与内存分配策略的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。