一、背景

Java是一種流行的編程語言，可以在不同的操作系統(tǒng)上運行。它具有跨平臺、面向對象、自動內(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ěn)定性，因為垃圾收集器可以自動檢測和清除不再使用的內(nèi)存資源，避免內(nèi)存溢出等問題。

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

名詞解釋：

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

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

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

二、Java 的內(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ū)域則是隨著用戶線程的啟動和結束而建立和銷毀。這些數(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)存的，是垃圾回收的主要目標和方向。
• 本地方法棧區(qū)域：Native Mehod Stack與Java虛擬機棧的作用非常相似，區(qū)別是Java虛擬機棧為虛擬機執(zhí)行Java方法或者為字節(jié)碼而服務，本地方法棧是為了Java 虛擬機棧得到Native方法。
• Java虛擬機棧區(qū)域：負責Java的解釋過程、程序的執(zhí)行過程、入棧和出棧，它是與線程相關的，當啟動一個新的線程時，Java程序就會分配一個Java 虛擬機棧提供運行；Java 虛擬機棧從方法入棧到具體字節(jié)碼執(zhí)行是一個雙層棧結構，可以棧里包含棧。
• 程序計數(shù)器：記錄線程執(zhí)行位置，線程私有，因為操作系統(tǒng)不停的調(diào)度，無法獲取到線程被調(diào)度之前的位置，程序計數(shù)器提供了這樣一個線程執(zhí)行位置。
• 元空間區(qū)域：在原來的老的Java 7之前劃分中，永久代用來存放類的元數(shù)據(jù)信息、靜態(tài)變量以及常量池等。在現(xiàn)在Java8后類的元信息存儲在元空間中，靜態(tài)變量和常量池等并入堆中，相當于原來的永久代中的數(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回收的主要目標是堆內(nèi)存，對象主要的創(chuàng)建分配內(nèi)存在堆上進行，堆可以想象成一個對象池子，對象不停創(chuàng)建放入池子中，而JVM垃圾回收是不停的回收池子中一些被標記為可回收對象的對象，啟動回收線程進行打掃戰(zhàn)場，當回收對象的速度趕不上程序的創(chuàng)建時，池子就會立馬滿，當滿了之后從而發(fā)生溢出，就是常見的OOM。

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

2.2 堆內(nèi)存管理

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

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

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

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

可回收對象：

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

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

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

（2）可達性分析法

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

2.2.2 GC Roots的概念和對象類型

1. Java 虛擬機棧中引用的對象，例如各個線程被調(diào)用的方法棧用到的參數(shù)、局部變量或者臨時變量等。
2. 方法區(qū)的靜態(tài)類屬性引用對象或者說Java類中的引用類型的靜態(tài)變量。
3. 方法區(qū)中的常量引用或者運行時常量池中的引用類型變量。
4. JVM內(nèi)部的內(nèi)存數(shù)據(jù)結構的一些引用、同步的監(jiān)控對象（被修飾同步鎖）。
5. JNI中的引用對象。

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

2.2.3 垃圾對象回收算法

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

（1）標記清除算法

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

（2）標記壓縮算法

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

（3）復制算法

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

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

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

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

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

（1）年輕代空間

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

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

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

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

（2）老年代空間

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

老年代對象：

1. 正常提升：由年輕代存活對象年齡到達閾值時，這個對象則會被移動到老年代中。
2. 分配擔保：如果年輕代中的空間不足時，此時有新的對象需要分配對象空間，需要依賴其它內(nèi)存進行分配擔保，老年代擔保直接創(chuàng)建。
3. 大對象：當創(chuàng)建需要大量連續(xù)內(nèi)存空間的對象時，如長字符串或者數(shù)組等，大小超過了閾值時，直接在老年代分配。
4. 動態(tài)年齡對象：有的垃圾收集器不需要到達指定年齡大小直接晉升老年代，比如相同年齡的對象的大小總和 > Survivor空間的50%， 年齡大于等于該年齡對象直接移動老年代，無需等待正常提升。

老年代回收發(fā)起Major GC / FULL GC，當老年代滿時會觸發(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ā)條件：

• 老年代空間不足。
• 元空間不足擴容導致。
• 程序代碼執(zhí)行System.gc時可能會執(zhí)行。
• 當程序創(chuàng)建一個大對象時，Eden區(qū)域放不下大對象，老年代內(nèi)存擔保分配，老年代也不足空間時。
• 年輕代存留對象晉升老年代時，老年代空間不足時。

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

 對象的分配過程

1. 編譯器通過逃逸分析優(yōu)化手段，確定對象是否在棧上分配還是堆上分配。
2. 如果在堆上分配，則確定是否大對象，如果是則直接進入老年代空間分配， 不然則走3。
3. 對比tlab， 如果tlab_top + size <= tlab_end， 則在tlab上直接分配，并且增加tlab_top值，如果tlab不足以空間放當前對象，則重新申請一個tlab嘗試放入當前對象，如果還是不行則往下走4。
4. 分配在Eden空間，當eden空間不足時發(fā)生YGC， 幸存者區(qū)是否年齡晉升、動態(tài)年齡、老年代剩余空間不足發(fā)生Full GC 。
5. 當YGC之后仍然不足當前對象放入，則直接分配老年代。

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

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

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收集器采用復制算法， 作用在年輕代的一款垃圾收集器，串行運行，執(zhí)行過程中會STW，是使用單個線程進行垃圾回收，響應速度優(yōu)先。

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

使用場景：

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

優(yōu)點：

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

缺點：

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

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

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

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

Parallel Scavenge + Parallel Old組合是Java8當中默認使用的一個組合垃圾回收。

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

使用場景：

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

優(yōu)點：

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

缺點：

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

（3）Par New垃圾收集器

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

使用場景：

搭配CMS使用

（4）CMS垃圾收集器

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

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

CMS分段

• 初始標記階段， 這個階段會暫停用戶線程， 掃描所有的根對象，因為根對象比較少，所以一般stw時間都非常短。
• 并發(fā)標記階段，這個階段與用戶線程一起執(zhí)行，會一直沿著根往下掃描，不停的識別對象是否為垃圾，標記，采用了三色算法， 在對象頭(Mark World)標識了一個顏色屬性，不同的顏色代表不同階段，掃描過程中給與對象一個顏色，記錄掃描位置，防止cpu時間片切換不需要重新掃描。
• 重新標記階段， 這個階段暫停用戶線程， 修正一些漏標對象，回掃發(fā)生引用變化的對象。
• 并發(fā)清理階段， 這個階段與用戶線程一起執(zhí)行，標記清除已經(jīng)成為垃圾的對象。

三色標記

• 黑色：代表了自己已經(jīng)被掃描完畢，并且自己的引用對象也已經(jīng)確定完畢。
• 灰色：代表自己已經(jīng)被掃描完畢了， 但是自己的引用還沒標記完。
• 白色：則代表還沒有被掃描過。

標記過程結束后，所有未被標記的對象都是不可達的，可以被回收。

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

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è)務線程發(fā)生了引用改變， 原本r.a.b的引用置為null
        r.a.b = null;
        // GC線程回來繼續(xù)上次掃描，發(fā)現(xiàn)r.a.b無引用，則認為b對象無任何引用清除
        r.b = b;
        // GC 回收了b， 業(yè)務線程無法使用b
    }
}
 
class R {
    A a;
    B b;
}
 
class A {
    B b;
}
 
class B {
}

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

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

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è)務線程發(fā)生引用切換， r置灰灰色（本身灰色）
        r.a1 = b;
        // GC線程繼續(xù)掃完a2， R為黑色， b對象又漏了~
    }
}
 
class R {
    A a1;
    A a2;
}
 
class A {
}

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

使用場景：

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

優(yōu)點：

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

缺點：

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

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

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

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

（5）G1垃圾收集器

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

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

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

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

Humingous：如果一個對象占用的空間超過了分區(qū)容量50%以上，G1收集器就認為這是一個巨型對象。這些巨型對象，默認直接會被分配在年老代，但是如果它是一個短期存在的巨型對象，就會對垃圾收集器造成負面影響；為了解決這個問題，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，當該card區(qū)域里的對象有引用關系，將當前card置為“dirty”， 并且使用卡表（CardTable）來記錄每一塊card是否dirty，在進行GC時，不用遍歷所有的空間， 只需要遍歷卡表中為"dirty"或者說布爾符合條件的card區(qū)域進行回掃。

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

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

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

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

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

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

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

使用場景：

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

優(yōu)點：

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

缺點：

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

執(zhí)行過程中額外負載開銷加大，寫屏障進行維護卡表操作外，還需要原始快照能夠減少并發(fā)標記和重新標記階段的消耗，避免最終標記階段停頓過長，運行過程中會產(chǎ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占比情況， 默認下 ParNew占用整個堆的空間為：機器位數(shù) * CPU核數(shù) * 13 /10 ， 當前機器配置計算得出 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默認ParallerGC收集器初始內(nèi)存劃分情況：

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

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

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

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

-XX:+HeapDumpOnOutOfMemoryError 

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

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

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

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

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

引用：Arthas 命令列表

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

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

用例  jhat E:\diydump\Java_pid2680.hprof

• All classes including platform：列舉應用程序中所有類的信息，并快速定位內(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應用程序的性能問題。使用它可以實時查看Java 應用程序的內(nèi)存使用情況、CPU使用情況、線程情況等，并可以進行內(nèi)存分析、CPU分析、線程分析等內(nèi)容。

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

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

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

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

• Overview 標簽內(nèi)容有比較多塊內(nèi)容，其中details末塊介紹總共使用內(nèi)存大小，類的數(shù)量，實例的數(shù)量，類的加載器，以及實例的內(nèi)存直方圖；
  
  
• Biggest Objects by Retained Size模塊，使用了餅狀圖列出了當前內(nèi)存中占用最大的幾個對象，按照百分比劃分，點擊不同的餅狀塊能夠看到具體對象及其對象屬性等信息；
• actions模塊，這里擁有不同的分析功能，Histogram生成視圖列出每個類所對應的對象個數(shù)以及占用內(nèi)存大小，Dominator Tree生成視圖尋找出大對象，每個實例對象的內(nèi)存占比比重；
• Reports模塊是生成報告，其中Leak Suspects可以自動分析內(nèi)存泄漏主要原因報告，可以通過報告準確定位泄漏原因或者可能造成泄漏的原因，并且可以定位到具體累積實例，線程stack等信息。

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

四、總結

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

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