作者：vivo 互聯(lián)網(wǎng)服務(wù)器團隊- Zeng Zhibin

介紹Java8虛擬機的內(nèi)存區(qū)域劃分、內(nèi)存垃圾回收工作原理解析、虛擬機內(nèi)存分配配置，介紹各垃圾收集器優(yōu)缺點及場景應(yīng)用、實踐內(nèi)存故障場景排查診斷，方便讀者面臨內(nèi)存故障時有一個明確的思路和方向。

一、背景

Java是一種流行的編程語言，可以在不同的操作系統(tǒng)上運行。它具有跨平臺、面向?qū)ο?、自動?nèi)存管理等特點，Java程序在運行時需要使用內(nèi)存來存儲數(shù)據(jù)和程序狀態(tài)。

Java的自動內(nèi)存管理機制是由 JVM 中的垃圾收集器來實現(xiàn)的，垃圾收集器會定期掃描堆內(nèi)存中的對象，檢測并清除不再使用的對象，以釋放內(nèi)存資源。

Java的自動內(nèi)存管理機制帶來了許多好處，首先，它可以避免程序員手動管理內(nèi)存時的錯誤，例如內(nèi)存泄漏和懸空指針等問題。其次，它可以提高程序的運行效率，因為程序員不需要頻繁地手動分配和釋放內(nèi)存，而是可以將更多時間和精力專注于程序的業(yè)務(wù)邏輯，最后，它可以提高程序的可靠性和穩(wěn)定性，因為垃圾收集器可以自動檢測和清除不再使用的內(nèi)存資源，避免內(nèi)存溢出等問題。

了解和掌握垃圾收集器原理可以幫助提高程序的性能、穩(wěn)定性和可維護性。

名詞解釋：

響應(yīng)速度：響應(yīng)速度指程序或系統(tǒng)對一個請求的響應(yīng)有多迅速。比如，用戶查詢數(shù)據(jù)響應(yīng)時間，對響應(yīng)速度要求很高的系統(tǒng)，較大的停頓時間是不可接受的。

吞吐量：吞吐量關(guān)注在一個特定時間段內(nèi)應(yīng)用系統(tǒng)的最大工作量，例如每小時批處理系統(tǒng)能完成的任務(wù)數(shù)量，在吞吐量方面優(yōu)化的系統(tǒng)，較長的GC停頓時間也是可以接受的，因為高吞吐量應(yīng)用更關(guān)心的是如何盡可能快地完成整個任務(wù)，不考慮快速響應(yīng)用戶請求。

GC導(dǎo)致的應(yīng)用暫停時間影響系統(tǒng)響應(yīng)速度，GC處理線程的CPU使用率影響系統(tǒng)吞吐量。

二、Java8的內(nèi)存管理

2.1 JVM（Java虛擬機）內(nèi)存劃分

Java運行時數(shù)據(jù)區(qū)域劃分，Java虛擬機在執(zhí)行Java程序時，將其所管理的內(nèi)存劃分為不同的數(shù)據(jù)區(qū)域，每個區(qū)域都有特定的用途和創(chuàng)建銷毀的時間。其中，有些區(qū)域在虛擬機進程啟動時就存在，而有些區(qū)域則是隨著用戶線程的啟動和結(jié)束而建立和銷毀。這些數(shù)據(jù)區(qū)域包括程序計數(shù)器、虛擬機棧、本地方法棧、堆、方法區(qū)等，每個區(qū)域都有其自身的特點和作用。了解這些數(shù)據(jù)區(qū)域的使用方式和特點，可以更好地理解Java虛擬機的內(nèi)存管理機制和運行原理。

JVM的內(nèi)存區(qū)域劃分可分為：1.堆內(nèi)存空間、2.Java虛擬機棧區(qū)域、3.程序計數(shù)器、4.本地方法棧、5.元空間區(qū)域、6.直接內(nèi)存。

堆內(nèi)存空間：JVM中占用內(nèi)存空間最大的是堆，平常對象的創(chuàng)建大部分都是在堆上分配內(nèi)存的，是垃圾回收的主要目標(biāo)和方向。

本地方法棧區(qū)域：Native Mehod Stack與Java虛擬機棧的作用非常相似，區(qū)別是Java虛擬機棧為虛擬機執(zhí)行Java方法或者為字節(jié)碼而服務(wù)，本地方法棧是為了Java 虛擬機棧得到Native方法。

Java虛擬機棧區(qū)域：負(fù)責(zé)Java的解釋過程、程序的執(zhí)行過程、入棧和出棧，它是與線程相關(guān)的，當(dāng)啟動一個新的線程時，Java程序就會分配一個Java 虛擬機棧提供運行；Java 虛擬機棧從方法入棧到具體字節(jié)碼執(zhí)行是一個雙層棧結(jié)構(gòu)，可以棧里包含棧。

程序計數(shù)器：記錄線程執(zhí)行位置，線程私有，因為操作系統(tǒng)不停的調(diào)度，無法獲取到線程被調(diào)度之前的位置，程序計數(shù)器提供了這樣一個線程執(zhí)行位置。

元空間區(qū)域：在原來的老的Java 7之前劃分中，永久代用來存放類的元數(shù)據(jù)信息、靜態(tài)變量以及常量池等。在現(xiàn)在Java8后類的元信息存儲在元空間中，靜態(tài)變量和常量池等并入堆中，相當(dāng)于原來的永久代中的數(shù)據(jù)，被元空間和堆內(nèi)存給瓜分了。

直接內(nèi)存：使用了Java 的直接內(nèi)存的API的內(nèi)存，例如緩沖ByteBuffer，可以控制虛擬機參數(shù)調(diào)整大小，而本地內(nèi)存是使用了native函數(shù)操作的內(nèi)存，是不受JVM管理控制。

堆內(nèi)存空間

JVM回收的主要目標(biāo)是堆內(nèi)存，對象主要的創(chuàng)建分配內(nèi)存在堆上進行，堆可以想象成一個對象池子，對象不停創(chuàng)建放入池子中，而JVM垃圾回收是不停的回收池子中一些被標(biāo)記為可回收對象的對象，啟動回收線程進行打掃戰(zhàn)場，當(dāng)回收對象的速度趕不上程序的創(chuàng)建時，池子就會立馬滿，當(dāng)滿了之后從而發(fā)生溢出，就是常見的OOM。

GC的速度和堆的內(nèi)存中存活對象的數(shù)量有關(guān)，與堆內(nèi)存所有的對象無關(guān)，GC的速度和堆內(nèi)存的大小無關(guān)，如一個4GB大小的堆內(nèi)存和一個16GB的堆內(nèi)存，只要2個堆內(nèi)存存活對象都是一樣多的時候，GC速度都是基本差不多。每次垃圾回收也不是必須要把垃圾清理干凈，重要的是保證不把正在使用的對象給標(biāo)記清除掉。

2.2 堆內(nèi)存管理

JVM中占用內(nèi)存空間最大的是堆內(nèi)存，平常對象的創(chuàng)建大部分都是在堆上分配內(nèi)存的，是Java垃圾回收的主要目標(biāo)和方向、是 Java內(nèi)存管理機制的核心組成部分，它可以自動管理 Java程序的內(nèi)存分配和釋放，Java垃圾收集器可以自動檢測和回收不再使用的內(nèi)存，以便重新分配給其他需要內(nèi)存的程序。這種自動內(nèi)存管理的機制可以提高程序的運行效率和可靠性，防止因內(nèi)存泄漏等問題導(dǎo)致程序崩潰或性能下降，Java 垃圾收集器使用了不同的垃圾回收算法和垃圾收集器實現(xiàn)，以適應(yīng)不同的應(yīng)用場景和需求。Java垃圾收集器的性能特征和優(yōu)化技術(shù)也是 Java程序員需要了解和掌握的重要知識。

因此，了解 Java垃圾回收的背景、原理和實踐經(jīng)驗對于編寫高效、可靠的 Java程序非常重要。

2.2.1 對象如何被判斷為可回收

JVM怎么判斷堆內(nèi)存里面的對象是否可回收的，就是當(dāng)一個對象沒有任何引用指向它了，它就是可回收對象，判斷的方式有兩種算法，一個是引用計數(shù)法，一個是可達(dá)性分析法。

可回收對象：

（1）引用計數(shù)法

給對象中添加一個引用計數(shù)器，每當(dāng)有一個地方引用它時，這個計數(shù)器值加一，當(dāng)引用失效斷開時，計數(shù)器值就減一，在任何時刻時計數(shù)器為0的時候，代表這個對象是可以被回收的，沒有任何引用使用它了。

引用計數(shù)法是有缺點，當(dāng)對象直接互相依賴引用時，這些對象的計數(shù)器都不能為0，都不能被回收。

（2）可達(dá)性分析法

它使用tracing（鏈路追蹤）方式尋找存活對象的方法，通過一些列稱為“GC Roots”的對象作為初始點，從這些初始點開始向下查找，直到向下查找沒有任何鏈路時，代表這個對象可以被回收，這種算法是目前Java唯一且默認(rèn)使用來判定可回收的算法。

2.2.2 GC Roots的概念和對象類型

Java 虛擬機棧中引用的對象，例如各個線程被調(diào)用的方法棧用到的參數(shù)、局部變量或者臨時變量等。

方法區(qū)的靜態(tài)類屬性引用對象或者說Java類中的引用類型的靜態(tài)變量。

方法區(qū)中的常量引用或者運行時常量池中的引用類型變量。

JVM內(nèi)部的內(nèi)存數(shù)據(jù)結(jié)構(gòu)的一些引用、同步的監(jiān)控對象（被修飾同步鎖）。

JNI中的引用對象。

當(dāng)然，被GC Roots追溯到的對象不是一定不會被垃圾回收，具體需要看情況，Java 對象與對象引用存在四種引用級別：分別是強引用、軟引用、弱引用、虛引用，默認(rèn)的對象關(guān)系是強引用，只有在和GCRoots沒有關(guān)系時才會被回收；軟引用用于維護一些可有可無的對象，當(dāng)內(nèi)存足夠時不會被回收；弱引用只要發(fā)生了垃圾回收就會被清理；虛引用人如其名形同虛設(shè)，任何對象都與它無關(guān)。

2.2.3 垃圾對象回收算法

當(dāng)JVM定位到了那些對象可回收時，這個時候是通過三個算法標(biāo)記清除，分別是標(biāo)記清除算法、復(fù)制算法、標(biāo)記壓縮算法。

（1）標(biāo)記清除算法

首先標(biāo)記出所有需要回 收的對象，在標(biāo)記完成后，統(tǒng)一回收掉所有被標(biāo)記的對象，但是該算法缺點是執(zhí)行效率低，當(dāng)大量對象時需要大量標(biāo)記和清理動作，而且容易產(chǎn)生內(nèi)存碎片化，當(dāng)需要一塊連續(xù)內(nèi)存時，會因為碎片化無法分配。

（2）標(biāo)記壓縮算法

標(biāo)記壓縮算法跟清除算法很像，只不過它對內(nèi)存進行了整理， 讓存活對象都向內(nèi)存空間的一端移動，然后將邊界的其它對象全部清理，這樣能達(dá)到內(nèi)存碎片化問題，不過它比清除算法多了移步動作。

（3）復(fù)制算法

為了解決標(biāo)記-清除算法面對大量可回收對象時執(zhí)行效率低的問題，將存活對象復(fù)制到一塊空置的空間里，然后將原來的區(qū)域全部清理，缺點是需要額外空間存放存活對象。

2.2.4 分代垃圾回收模型概念和原理

堆內(nèi)存分代模型圖

當(dāng)JVM進行GC（垃圾回收）時，JVM會發(fā)起“Stop the world”，所有的業(yè)務(wù)線程都進行停止，進入SafePoint狀態(tài)，JVM回收垃圾線程開始進行標(biāo)記和追溯，如何解決這種停止和如何減少STW的時間呢？

目前主流垃圾收集器采用分代垃圾回收方式，大部分對象的聲明周期都比較短，只有少部分的對象才存活的比較長，分代垃圾回收會在邏輯上把堆內(nèi)存空間分為兩部分，一部分為年輕代，一部分為老年代。

（1）年輕代空間

年輕代主要是存放新生成的對象，一般占用堆空間的三分之一空間，因為會頻繁創(chuàng)建對象，所以年輕代GC頻率是最高的。

分為Eden空間、Survivor1（from）區(qū)、Survivor2（to）區(qū)，S1和S2總要有一塊空間是空的，為了方便年輕代存活對象來回存放，晉升存活對象年齡。

三個區(qū)的默認(rèn)比例是81，可以通過配置參數(shù)調(diào)整比例。

年輕代回收發(fā)起Minor GC（YongGC），當(dāng)Eden內(nèi)存區(qū)域被占滿之后就發(fā)起GC，短暫的STW，基于垃圾收集器。

（2）老年代空間

是堆內(nèi)存中最大的空間， ，里面的對象都是比較穩(wěn)定或者老頑固，GC頻率不會頻繁執(zhí)行。

老年代對象：

正常提升：由年輕代存活對象年齡到達(dá)閾值時，這個對象則會被移動到老年代中。

分配擔(dān)保：如果年輕代中的空間不足時，此時有新的對象需要分配對象空間，需要依賴其它內(nèi)存進行分配擔(dān)保，老年代擔(dān)保直接創(chuàng)建。

大對象：當(dāng)創(chuàng)建需要大量連續(xù)內(nèi)存空間的對象時，如長字符串或者數(shù)組等，大小超過了閾值時，直接在老年代分配。

動態(tài)年齡對象：有的垃圾收集器不需要到達(dá)指定年齡大小直接晉升老年代，比如相同年齡的對象的大小總和 > Survivor空間的50%， 年齡大于等于該年齡對象直接移動老年代，無需等待正常提升。

老年代回收發(fā)起Major GC / FULL GC，當(dāng)老年代滿時會觸發(fā)MajorGC，通常至少經(jīng)歷過一次Minor GC，再緊接著進行Major GC， Major GC清理Tenured區(qū)，用于回收老年代（CMS才能單獨清理）。

FUll GC：清除整個堆空間，一般來說是針對整個新生代、老生代、元空間的全局范圍的清理。

不管是Major GC還是 Full GC， STW的耗時都是Ygc的十倍以上，所以說對象能在年輕代被回收是最優(yōu)的。

Full GC觸發(fā)條件：

老年代空間不足。

元空間不足擴容導(dǎo)致。

程序代碼執(zhí)行System.gc時可能會執(zhí)行。

當(dāng)程序創(chuàng)建一個大對象時，Eden區(qū)域放不下大對象，老年代內(nèi)存擔(dān)保分配，老年代也不足空間時。

年輕代存留對象晉升老年代時，老年代空間不足時。

2.2.5 Java對象內(nèi)存分配過程

對象的分配過程

編譯器通過逃逸分析優(yōu)化手段，確定對象是否在棧上分配還是堆上分配。

如果在堆上分配，則確定是否大對象，如果是則直接進入老年代空間分配， 不然則走3。

對比tlab， 如果tlab_top + size <= tlab_end， 則在tlab上直接分配，并且增加tlab_top值，如果tlab不足以空間放當(dāng)前對象，則重新申請一個tlab嘗試放入當(dāng)前對象，如果還是不行則往下走4。

分配在Eden空間，當(dāng)eden空間不足時發(fā)生YGC， 幸存者區(qū)是否年齡晉升、動態(tài)年齡、老年代剩余空間不足發(fā)生Full GC 。

當(dāng)YGC之后仍然不足當(dāng)前對象放入，則直接分配老年代。

TLAB作用原理：Java在內(nèi)存新生代Eden區(qū)域開辟了一小塊線程私有區(qū)域，這塊區(qū)域為TLAB，默認(rèn)占Eden區(qū)域大小的1%， 作用于小對象，因為小對象用完即丟，不存在線程共享，快速消亡GC，JVM優(yōu)先將小對象分配在TLAB是線程私有的，所以沒有鎖的開銷，效率高，每次只需要線程在自己的緩沖區(qū)分配即可，不需要進行鎖同步堆 。

對象除了基本類型的不一定是在堆內(nèi)存分配，在JVM擁有逃逸分析，能夠分析出一個新的對象所擁有的范圍，從而決定是否要將這個對象分配到堆上，是JVM的默認(rèn)行為；Java 逃逸分析是一種優(yōu)化技術(shù)，可以通過分析 Java 對象的作用域和生命周期，確定對象的內(nèi)存分配位置和生命周期，從而減少不必要的內(nèi)存分配和垃圾回收?？梢栽跅Ｉ戏峙洌梢栽跅蟿?chuàng)建和銷毀，分離對象或標(biāo)量替換，同步消除。

public class TaoYiFenxi {
 
    Object obj;
 
    public void setObj() {
        obj = new Object();
    }
 
    public Object getObject() {
        Object obj1 = new Object();
        return obj1;
    }
 
 
    public void test1() {
        synchronized (new Object()) {
 
        }
    }
 
}

2.2.6 JVM垃圾收集器特點與原理

（1）Serial垃圾收集器、Serial Old垃圾收集器

Serial收集器采用復(fù)制算法， 作用在年輕代的一款垃圾收集器，串行運行，執(zhí)行過程中會STW，是使用單個線程進行垃圾回收，響應(yīng)速度優(yōu)先。

Serial Old 收集器采用標(biāo)記整理算法，作用在老年代的一款收集器，串行運行，執(zhí)行過程中會暫停所有用戶線程，會STW，使用單個線程進行垃圾回收，響應(yīng)速度優(yōu)先。

使用場景：

適合內(nèi)存小幾十兆以內(nèi)，比較適合簡單的服務(wù)或者單CPU服務(wù)，避免了線程交互的開銷。

優(yōu)點：

小堆內(nèi)存且單核CPU執(zhí)行效率高。

缺點：

堆內(nèi)存大，多核CPU不適合，回收時長非常長。

（2）Parallel Scavenge垃圾收集器、Parallel Old垃圾收集器

Parallel Scavenge垃圾收集器采用了復(fù)制算法，作用在年輕代的一款垃圾收集器，是并行的多線程運行，執(zhí)行過程中會發(fā)生STW，關(guān)注與程序吞吐量。

Parallel Old垃圾收集器采用標(biāo)記整理算法，作用，作用在老年代的一款垃圾收集器， 是并行的多線程運行，執(zhí)行過程中會發(fā)生STW，關(guān)注與程序吞吐量。

Parallel Scavenge + Parallel Old組合是Java8當(dāng)中默認(rèn)使用的一個組合垃圾回收。

所謂的吞吐量是CPU用于運行用戶代碼時間與CPU總消耗時間的比值，也就是說吞吐量 = 運行用戶代碼時間 / (運行用戶代碼時間 + 垃圾收集器時間)， 錄入程序運行了100分鐘，垃圾收集器花費時間1分鐘，則吞吐量達(dá)到了99%。

使用場景：

適用于內(nèi)存在幾個G之間，適用于后臺計算服務(wù)或者不需要太多交互的服務(wù)，保證吞吐量的服務(wù)。

優(yōu)點：

可控吞吐量、保證吞吐量，并行收集。

缺點：

回收期間STW，隨著堆內(nèi)存增大，回收暫停時間增大。

（3）Par New垃圾收集器

Par New垃圾收集器采用了復(fù)制算法，作用在年輕代的一款垃圾收集器， 也是并行多線程運行，跟Parallel非常相似，是它的增強版本，或者說是Serial收集器的多線程版本，是搭配CMS垃圾收集器特制的一個收集器。

使用場景：

搭配CMS使用

（4）CMS垃圾收集器

CMS是一款多線程+分段操作的一款垃圾收集器。其最大的優(yōu)點就是將一次完整的回收過程拆分成多個步驟，并且在執(zhí)行的某些過程中可以使用戶線程可以繼續(xù)運行，分別有初始標(biāo)記，并發(fā)標(biāo)記，重新標(biāo)記，并發(fā)清理和并發(fā)重置。

CMS是一款多線程+分段操作的一款垃圾收集器。其最大的優(yōu)點就是將一次完整的回收過程拆分成多個步驟，并且在執(zhí)行的某些過程中可以使用戶線程可以繼續(xù)運行，分別有初始標(biāo)記，并發(fā)標(biāo)記，重新標(biāo)記，并發(fā)清理和并發(fā)重置。

CMS分段

初始標(biāo)記階段， 這個階段會暫停用戶線程， 掃描所有的根對象，因為根對象比較少，所以一般stw時間都非常短。

并發(fā)標(biāo)記階段，這個階段與用戶線程一起執(zhí)行，會一直沿著根往下掃描，不停的識別對象是否為垃圾，標(biāo)記，采用了三色算法， 在對象頭(Mark World)標(biāo)識了一個顏色屬性，不同的顏色代表不同階段，掃描過程中給與對象一個顏色，記錄掃描位置，防止cpu時間片切換不需要重新掃描。

重新標(biāo)記階段， 這個階段暫停用戶線程， 修正一些漏標(biāo)對象，回掃發(fā)生引用變化的對象。

并發(fā)清理階段， 這個階段與用戶線程一起執(zhí)行，標(biāo)記清除已經(jīng)成為垃圾的對象。

三色標(biāo)記

黑色：代表了自己已經(jīng)被掃描完畢，并且自己的引用對象也已經(jīng)確定完畢。

灰色：代表自己已經(jīng)被掃描完畢了， 但是自己的引用還沒標(biāo)記完。

白色：則代表還沒有被掃描過。

標(biāo)記過程結(jié)束后，所有未被標(biāo)記的對象都是不可達(dá)的，可以被回收。

三色標(biāo)記算法的問題場景：當(dāng)業(yè)務(wù)線程做了對象引用變更，會發(fā)生B對象不會被掃描，當(dāng)成垃圾回收。

public class Demo3 {
 
    public static void main(String[] args) {
        R r = new R();
        r.a = new A();
        B b = new B();
        // GCroot遍歷R， R為黑色， R下面的a引用鏈還未掃完置灰灰色，R.b無引用， 切換時間分片
        r.a.b = b;
        // 業(yè)務(wù)線程發(fā)生了引用改變， 原本r.a.b的引用置為null
        r.a.b = null;
        // GC線程回來繼續(xù)上次掃描，發(fā)現(xiàn)r.a.b無引用，則認(rèn)為b對象無任何引用清除
        r.b = b;
        // GC 回收了b， 業(yè)務(wù)線程無法使用b
    }
}
 
class R {
    A a;
    B b;
}
 
class A {
    B b;
}
 
class B {
}

當(dāng)GC線程標(biāo)記A時，CPU時間片切換，業(yè)務(wù)線程進行了對象引用改變，這時候時間片回到了GC線程，繼續(xù)掃描對象A， 發(fā)現(xiàn)A沒有任何引用，則會將A賦值黑色掃描完畢，這樣B則不會被掃描，會標(biāo)記B是垃圾， 在清理階段將B回收掉，錯誤的回收正常的對象，發(fā)生業(yè)務(wù)異常。

CMS基于這種錯誤標(biāo)記的解決方案是采取寫屏障 + 增量更新Incremental Update ， 在業(yè)務(wù)線程發(fā)生對象變化時，重新將R標(biāo)識為灰色，重新掃描一遍，Incremental Update 在特殊場景下還是會產(chǎn)生漏標(biāo)。

public class Demo3 {
 
    public static void main(String[] args) {
        // Incremental Update還會產(chǎn)生的問題
        R r = new R();
        A a = new A();
        A b = new A();
        r.a1 = a;
        // GC線程切換， r掃完a1， 但是沒有掃完a2， 還是灰色
        r.a2 = b;
        // 業(yè)務(wù)線程發(fā)生引用切換， r置灰灰色（本身灰色）
        r.a1 = b;
        // GC線程繼續(xù)掃完a2， R為黑色， b對象又漏了~
    }
}
 
class R {
    A a1;
    A a2;
}
 
class A {
}

當(dāng)GC 1線程正在標(biāo)記O， 已經(jīng)標(biāo)記完O的屬性 O.1， 準(zhǔn)備標(biāo)記O.2時，業(yè)務(wù)線程把屬性O(shè),1 = B，這時候?qū)對象再次標(biāo)記成灰色， GC 1線程切回，將O.2線程標(biāo)記完成，這時候認(rèn)為O已經(jīng)全部標(biāo)記完成，O標(biāo)記為黑色， B對象產(chǎn)生了漏標(biāo)， CMS針對Incremental Update產(chǎn)生的問題，只能在remark階段，暫停所有線程，將這些發(fā)生過引用改變過的，重新掃描一遍。

使用場景：

適用于互聯(lián)網(wǎng)或者 B/S服務(wù)， 響應(yīng)速度優(yōu)先，適合6G左右。

優(yōu)點：

并發(fā)收集， 低停頓，回收過程中最耗時的是并發(fā)標(biāo)記和并發(fā)清除，它都能與用戶線程保持一起工作。

缺點：

收集器對CPU的資源非常敏感，會占用用戶線程部分使用，導(dǎo)致程序會變得緩慢，吞吐量下降。

無法處理浮動垃圾，在并發(fā)清理階段用戶線程還是在運行，這時候產(chǎn)生的新垃圾無法在這次當(dāng)中處理，只有等待下次才會清理。

因為CMS使用了Incremental Update，remark階段還是會所有暫停，重新掃描發(fā)生引用改變的GC root，效率慢耗時高。

因為收集器是基于標(biāo)記清除算法實現(xiàn)的，所以在收集器回收結(jié)束后，內(nèi)存會產(chǎn)生碎片化，當(dāng)碎片化非常嚴(yán)重的時候，這時候有大對象進入無法分配內(nèi)存時會觸發(fā)FullGC，特殊場景下會使用Serial收集器，導(dǎo)致停頓不可控。

（5）G1垃圾收集器

G1也是采用三色標(biāo)記分段式進行回收的算法， 不過它是寫屏障 + STAB快照實現(xiàn)，G1設(shè)定的目標(biāo)是在延遲可控（低暫停）的情況下獲得盡可能高的吞吐量，仍然可以通過并發(fā)的方式讓Java 程序繼續(xù)運行，G1垃圾收集器在很多方面彌補了CMS的不足，比如CMS使用的是mark-sweep標(biāo)記清除算法，自然會產(chǎn)生內(nèi)存碎片(CMS只能在Full GC時，STW 整理內(nèi)存碎片)，然而G1整體來看是基于標(biāo)記整理算法實現(xiàn)的收集器，但是從局部來看也是基于復(fù)制算法實現(xiàn)的，高效的整理剩余內(nèi)存，而不需要管理內(nèi)存碎片它。

G1同樣有年輕代和老年代的概念，只不過物理空間劃分已經(jīng)不存在，邏輯分區(qū)還存在，G1會把堆切成若干份，每一份當(dāng)作一個目標(biāo)，在部分上目標(biāo)很容易達(dá)成，G1在進行垃圾回收的時候，將會根據(jù)最大停頓時間設(shè)置值動態(tài)選取部分小堆區(qū)垃圾回收。

G1的特點是盡量追求吞吐量，追求響應(yīng)時間，并發(fā)收集，壓縮空閑空間不會延長GC暫停時間，更容易預(yù)測GC暫停時間，能充分利用CPU、多核環(huán)境下的硬件優(yōu)勢，使用多個CPU對STW進行控制(200ms以內(nèi))靈活的分區(qū)回收，優(yōu)先回收花費時間少的或者垃圾比例高的region新老比例也是動態(tài)調(diào)整，不需要配置；年齡晉升也是15，但是可以動態(tài)年齡，當(dāng)幸存者region超過了50時，會把年齡最大的放入老年代。

G1動態(tài)Y區(qū)域設(shè)置，G1每個分區(qū)都可能是年輕代或者老年代，但是同一時刻只屬于一個代，分代概念還存在，邏輯上分代方便復(fù)用以前分代邏輯，在物理上不需要連續(xù)，這樣能帶來額外好處，有的分區(qū)內(nèi)垃圾比較多，有的分區(qū)比較少，G1會優(yōu)先回收垃圾比較多的分區(qū)，這樣可以花費少量的時間來回收這些分區(qū)垃圾，即收集最多垃圾分區(qū)；但是新生代回收不適合這種，新生代達(dá)到閾值時發(fā)生YGC，對整個新生代進行回收或者晉升幸存，新生代也分區(qū)是方便動態(tài)調(diào)整分區(qū)大小，在進行垃圾回收時，會將存活對象拷貝到另一個可用分區(qū)上，這樣也能避免一定程度的內(nèi)存碎片化過程，每個分區(qū)的大小都是在1M- 32M之間，取決2的冪次方。

Humingous：如果一個對象占用的空間超過了分區(qū)容量50%以上，G1收集器就認(rèn)為這是一個巨型對象。這些巨型對象，默認(rèn)直接會被分配在年老代，但是如果它是一個短期存在的巨型對象，就會對垃圾收集器造成負(fù)面影響；為了解決這個問題，G1劃分了一個Humongous區(qū)，它用來專門存放巨型對象。如果一個H區(qū)裝不下一個巨型對象，那么G1會尋找連續(xù)的H分區(qū)來存儲。為了能找到連續(xù)的H區(qū)，有時候不得不啟動Full GC。

CardTable：記錄每一塊card內(nèi)存區(qū)域是否dirty，如果在發(fā)生YGC時，怎么知道那些是存活對象，并且其它代區(qū)域有沒有引用這部分對象，于是把內(nèi)存劃分了很多card區(qū)域， 每個區(qū)域大小不超過512b，當(dāng)該card區(qū)域里的對象有引用關(guān)系，將當(dāng)前card置為“dirty”， 并且使用卡表（CardTable）來記錄每一塊card是否dirty，在進行GC時，不用遍歷所有的空間， 只需要遍歷卡表中為"dirty"或者說布爾符合條件的card區(qū)域進行回掃。

CSet：Collection SET用于記錄可被回收分區(qū)的集合組， G1使用不同算法，動態(tài)的計算出那些分區(qū)是需要被回收的，將其放到CSet中，在CSet當(dāng)中存活的數(shù)據(jù)都會在GC過程中拷貝到另一個可用分區(qū)，CSet可以是所有類型分區(qū)，它需要額外占用內(nèi)存，堆空間的1%。

RSet：RememberedSet 每個Region都有一個Rset，是一個記錄了其他Region中的對象到本身Region的引用，它可以使得垃圾收集器不需要掃描整個堆去找到誰的引用了當(dāng)前分區(qū)對象，是G1高效回收的關(guān)鍵點，也是三色算法的一個以來點。

RSet和卡表的區(qū)別是什么？

卡表記錄的是堆內(nèi)存中card有沒有變成"dirty"， 但是它本身不知道dirty里面哪些是引用了的對象，它是一個大維度的一個記錄，RSet是記錄自身Region中對象引用了其它Region中的那些對象，詳細(xì)的記錄對方引用對象信息，G1使用了兩者的結(jié)合，實現(xiàn)了增量式的垃圾回收，并優(yōu)化跨區(qū)引用的最終處理。

SATB算法：是一種基于快照的算法，它可以避免在垃圾回收時出現(xiàn)對象漏標(biāo)或者重復(fù)標(biāo)記的問題，從而提高垃圾回收的準(zhǔn)確性和效率，在垃圾回收開始時，對堆中的對象引用進行快照，然后在并發(fā)標(biāo)記階段中記錄下所有被修改過對象引用，保存到satb_mark_queue中，最后在重新標(biāo)記階段重新掃描這些對象，標(biāo)記所有被修改的對象，保證了準(zhǔn)確性和效率。

SATB算法在remark階段不需要暫停遍歷整個堆對象，只需要掃描“satb_mark_queue”隊列中的記錄，避免了這個階段長耗時，而cms的增量算法在這個階段是需要重新掃描GC Roots標(biāo)記整個堆對象，導(dǎo)致了不可控時間暫停，總的來說G1是通過回收領(lǐng)域應(yīng)用并行化策略，將原來的幾塊大內(nèi)存塊回收問題，演變成了N個小內(nèi)存塊回收，使得回收效率可以高度并行化，停頓時間可控，可以與用戶線程并發(fā)執(zhí)行，將一塊內(nèi)存分而治之。

G1默認(rèn)當(dāng)分區(qū)內(nèi)存占用閾值達(dá)到總內(nèi)存的45%，會發(fā)生Mixed gc（混和GC），YoungGC + 并發(fā)回收Mixed GC過程：初始標(biāo)記（stw）、并發(fā)標(biāo)記、最終標(biāo)記(重新標(biāo)記stw)、篩選回收（stw并行）。

使用場景：

響應(yīng)速度優(yōu)先，較高的吞吐量，面向服務(wù)端，使用內(nèi)存6G以上。

優(yōu)點：

并行與并發(fā)收集，分代分區(qū)收集，優(yōu)先垃圾收集，空間整合，可控或者可預(yù)測停頓時間。

缺點：

收集中產(chǎn)生內(nèi)存，G1的每個region都需要有一份記憶集和卡表記錄跨代指針，這導(dǎo)致記憶集可能占用堆空間10-20%甚至更多空間。

執(zhí)行過程中額外負(fù)載開銷加大，寫屏障進行維護卡表操作外，還需要原始快照能夠減少并發(fā)標(biāo)記和重新標(biāo)記階段的消耗，避免最終標(biāo)記階段停頓過長，運行過程中會產(chǎn)生由跟蹤引用變化帶來的額外開銷負(fù)擔(dān)，比CMS增量算法消耗更多，CMS的寫屏障實現(xiàn)直接是同步操作， 而G1是把寫屏障和寫后屏障中要做的事情放到隊列里異步處理。

G1對于Full GC是沒有處理流程， 一旦發(fā)生Full GC G1的回收執(zhí)行的是單線程的Serial回收器進行回收。

2.2.7 垃圾收集器配置使用

機器配置：64位 4C8G

Java 程序使用CMS收集器進行內(nèi)存垃圾回收初始內(nèi)存劃分情況：

-Xms4096M-Xmx4096M-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=/data/{runuser}/logs/other-XX:+UseConcMarkSweepGC

CMS 跟 parNew占比情況， 默認(rèn)下 ParNew占用整個堆的空間為：機器位數(shù) * CPU核數(shù) * 13 /10 ， 當(dāng)前機器配置計算得出 64 * 4 * 13 / 10 = 332M ， 與圖上數(shù)值差別不大。

Java程序使用G1收集器進行內(nèi)存垃圾回收初始內(nèi)存劃分情況：

-Xms4096M-Xmx4096M-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=/data/{runuser}/logs/other-XX:+UseG1GC

G1 新老年代的占比是動態(tài)調(diào)整， 隨著運行時根據(jù)實際情況劃分空間。

Java8默認(rèn)ParallerGC收集器初始內(nèi)存劃分情況：

parallel GC回收器默認(rèn)堆old區(qū)與young區(qū)內(nèi)存大小比例 2：1， 圖上數(shù)值差別不大。

三、內(nèi)存診斷實踐

3.1 內(nèi)存快照生成

當(dāng)發(fā)生線上應(yīng)用告警，告警相關(guān)內(nèi)存故障問題時， 應(yīng)當(dāng)如何進行故障排查呢？首先應(yīng)用在發(fā)生內(nèi)存溢出無法執(zhí)行時，應(yīng)DUMP當(dāng)前內(nèi)存快照，需要在Java程序執(zhí)行啟動命令時添加上：

-XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=${filePath} 參數(shù)

當(dāng)發(fā)生時自動生成一份當(dāng)前內(nèi)存快照，方便與開發(fā)人員使用快照文件進行問題診斷分析。

在Java應(yīng)用運行時，想手動生成內(nèi)存快照，可以使用JDK自帶幾個問題排查工具，可以使用jmap工具生成指定PID內(nèi)存快照，不過需要耗費較長的一個時間，會暫停應(yīng)用程序執(zhí)行，使用jcmd工具可以快速的DUMP內(nèi)存快照，因為在堆轉(zhuǎn)儲存文件過程中，jcmd可以利用虛擬機中的一些優(yōu)化技術(shù)，例如分代堆、增量式垃圾回收等技術(shù)，相比傳統(tǒng)的jmap效率高很多，一般來說在DUMP內(nèi)存前會進行一次

Full FC，可以指定屏蔽這次Full GC，保留當(dāng)前所有內(nèi)存中的對象。

除了自帶的內(nèi)存診斷工具， 也可以使用Arthas診斷工具，提供了多個命令來幫助診斷內(nèi)存問題，例如 dashboard（當(dāng)前Java程序內(nèi)存實時數(shù)據(jù)面板）、JVM（查看當(dāng)前JVM信息，包括使用的gc收集器、內(nèi)存分區(qū)分布情況等信息）、heapdump（當(dāng)前內(nèi)存快照類似jmap命令的heap dump）、memory（當(dāng)前內(nèi)存分區(qū)及占用情況）、monitor（監(jiān)控模式，可監(jiān)控內(nèi)存及查看對象占用情況）profiler（火焰圖可以輸出多種火焰圖，內(nèi)存分區(qū)占用火焰圖）等相關(guān)內(nèi)存命令。這些命令可以幫助獲取應(yīng)用程序的內(nèi)存快照、堆內(nèi)存使用情況等信息，能快速定位內(nèi)存問題。

引用：Arthas 命令列表

3.2 dump內(nèi)存快照分析

（1）jhat 是 Java 開發(fā)工具包自帶的一款堆內(nèi)存分析工具，它可以幫助解決 Java 應(yīng)用程序的內(nèi)存問題。Jhat 可以讀取 Java 應(yīng)用程序生成的堆轉(zhuǎn)儲文件，并以 HTML 格式展示內(nèi)存中的對象信息和引用關(guān)系，支持 OQL 查詢和靈活的過濾和排序功能。

用例 jhat E:diydumpJava_pid2680.hprof

All classes including platform：列舉應(yīng)用程序中所有類的信息，并快速定位內(nèi)存問題。

Show all members of the rootset：顯示堆內(nèi)存中所有根對象的信息，包括系統(tǒng)對象、靜態(tài)對象、本地對象等。

Show instance counts for all classes (including platform)：顯示所有類的實例數(shù)量。

Show heap histogram：顯示程序堆內(nèi)存的直方圖，可以知道每個類的實例數(shù)量和占用內(nèi)存大小等信息，快速知道內(nèi)存泄漏原因。

（2）jvisualvm也是Java 開發(fā)工具包里自帶的一款圖形化工具，可以用于監(jiān)控和診斷Java應(yīng)用程序的性能問題。使用它可以實時查看Java 應(yīng)用程序的內(nèi)存使用情況、CPU使用情況、線程情況等，并可以進行內(nèi)存分析、CPU分析、線程分析等內(nèi)容。

以Java_pid2680.hprof為例，進行內(nèi)存分析內(nèi)存泄漏原因：

（3）MAT 是基于Eclipse的內(nèi)存分析工具，是一個快速、功能豐富的Java內(nèi)存分析工具，能夠快速的分析出dump文件中各項結(jié)果，快速給出內(nèi)存泄漏原因報告。

還是以Java_pid2680.hprof文件進行分析，比原生的jhat方便很多，功能也比原生的更加豐富：

MAT的一些常用功能點介紹（如圖所示）：

Overview 標(biāo)簽內(nèi)容有比較多塊內(nèi)容，其中details末塊介紹總共使用內(nèi)存大小，類的數(shù)量，實例的數(shù)量，類的加載器，以及實例的內(nèi)存直方圖；

Biggest Objects by Retained Size模塊，使用了餅狀圖列出了當(dāng)前內(nèi)存中占用最大的幾個對象，按照百分比劃分，點擊不同的餅狀塊能夠看到具體對象及其對象屬性等信息；

actions模塊，這里擁有不同的分析功能，Histogram生成視圖列出每個類所對應(yīng)的對象個數(shù)以及占用內(nèi)存大小，Dominator Tree生成視圖尋找出大對象，每個實例對象的內(nèi)存占比比重；

Reports模塊是生成報告，其中Leak Suspects可以自動分析內(nèi)存泄漏主要原因報告，可以通過報告準(zhǔn)確定位泄漏原因或者可能造成泄漏的原因，并且可以定位到具體累積實例，線程stack等信息。

例子中：leak Suspects報告給出“0xfe3be480” 非常多內(nèi)存， Gc root Thread 所引用，在發(fā)生gc時，不是可回收對象，無法回收內(nèi)存，導(dǎo)致內(nèi)存溢出。

四、總結(jié)

本文介紹了Java程序中的內(nèi)存模型，內(nèi)存模型劃分多份內(nèi)存區(qū)域，不同區(qū)域的作用介紹及不同區(qū)域的線程之間的內(nèi)存共享范圍，可以幫助開發(fā)人員更加理解Java 中內(nèi)存管理的機制和原理。

堆是內(nèi)存模型中最大的一塊內(nèi)存區(qū)域，以堆的空間劃分詳細(xì)的介紹了內(nèi)存分代，部分垃圾收集器即是物理分代和邏輯分代，G1收集器則物理不分代邏輯保留了以前分代，講述了不同收集器的原理實現(xiàn)和優(yōu)缺點，可以根據(jù)項目的業(yè)務(wù)屬性，機器配置等因素選擇最優(yōu)的收集器，幫助程序使用最優(yōu)的收集器可以使得程序的吞吐量和響應(yīng)速度達(dá)到最佳狀態(tài)。還講述了不同的參數(shù)調(diào)優(yōu)收集器，并且當(dāng)發(fā)生了程序內(nèi)存溢出崩潰，如何進行內(nèi)存分析，介紹不同工具的使用，快速定位內(nèi)存溢出的罪魁禍?zhǔn)祝瑥亩诖a層面上根本解決這類問題。

審核編輯：黃飛