作者：vivo 互聯網服務器團隊- Zeng Zhibin

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

一、背景

Java是一種流行的編程語言，可以在不同的操作系統上運行。它具有跨平臺、面向對象、自動內存管理等特點，Java程序在運行時需要使用內存來存儲數據和程序狀態。

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

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

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

名詞解釋：

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

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

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

二、Java 8 的內存管理

2.1 JVM（Java虛擬機）內存劃分

Java運行時數據區域劃分，Java虛擬機在執行Java程序時，將其所管理的內存劃分爲不同的數據區域，每個區域都有特定的用途和創建銷燬的時間。其中，有些區域在虛擬機進程啓動時就存在，而有些區域則是隨着用戶線程的啓動和結束而建立和銷燬。這些數據區域包括程序計數器、虛擬機棧、本地方法棧、堆、方法區等，每個區域都有其自身的特點和作用。瞭解這些數據區域的使用方式和特點，可以更好地理解Java虛擬機的內存管理機制和運行原理。

JVM的內存區域劃分可分爲：1.堆內存空間、2.Java虛擬機棧區域、3.程序計數器、4.本地方法棧、5.元空間區域、6.直接內存。

堆內存空間：JVM中佔用內存空間最大的是堆，平常對象的創建大部分都是在堆上分配內存的，是垃圾回收的主要目標和方向。
本地方法棧區域：Native Mehod Stack與Java虛擬機棧的作用非常相似，區別是Java虛擬機棧爲虛擬機執行Java方法或者爲字節碼而服務，本地方法棧是爲了Java 虛擬機棧得到Native方法。
Java虛擬機棧區域：負責Java的解釋過程、程序的執行過程、入棧和出棧，它是與線程相關的，當啓動一個新的線程時，Java程序就會分配一個Java 虛擬機棧提供運行；Java 虛擬機棧從方法入棧到具體字節碼執行是一個雙層棧結構，可以棧裏包含棧。
程序計數器：記錄線程執行位置，線程私有，因爲操作系統不停的調度，無法獲取到線程被調度之前的位置，程序計數器提供了這樣一個線程執行位置。
元空間區域：在原來的老的Java 7之前劃分中，永久代用來存放類的元數據信息、靜態變量以及常量池等。在現在Java8後類的元信息存儲在元空間中，靜態變量和常量池等併入堆中，相當於原來的永久代中的數據，被元空間和堆內存給瓜分了。
直接內存：使用了Java 的直接內存的API的內存，例如緩衝ByteBuffer，可以控制虛擬機參數調整大小，而本地內存是使用了native函數操作的內存，是不受JVM管理控制。

堆內存空間

JVM回收的主要目標是堆內存，對象主要的創建分配內存在堆上進行，堆可以想象成一個對象池子，對象不停創建放入池子中，而JVM垃圾回收是不停的回收池子中一些被標記爲可回收對象的對象，啓動回收線程進行打掃戰場，當回收對象的速度趕不上程序的創建時，池子就會立馬滿，當滿了之後從而發生溢出，就是常見的OOM。

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

2.2 堆內存管理

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

因此，瞭解 Java垃圾回收的背景、原理和實踐經驗對於編寫高效、可靠的 Java程序非常重要。

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

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

可回收對象：

（1）引用計數法

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

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

（2）可達性分析法

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

2.2.2 GC Roots的概念和對象類型

Java 虛擬機棧中引用的對象，例如各個線程被調用的方法棧用到的參數、局部變量或者臨時變量等。
方法區的靜態類屬性引用對象或者說Java類中的引用類型的靜態變量。
方法區中的常量引用或者運行時常量池中的引用類型變量。
JVM內部的內存數據結構的一些引用、同步的監控對象（被修飾同步鎖）。
JNI中的引用對象。

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

2.2.3 垃圾對象回收算法

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

（1）標記清除算法

首先標記出所有需要回收的對象，在標記完成後，統一回收掉所有被標記的對象，但是該算法缺點是執行效率低，當大量對象時需要大量標記和清理動作，而且容易產生內存碎片化，當需要一塊連續內存時，會因爲碎片化無法分配。

（2）標記壓縮算法

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

（3）複製算法

爲了解決標記-清除算法面對大量可回收對象時執行效率低的問題，將存活對象複製到一塊空置的空間裏，然後將原來的區域全部清理，缺點是需要額外空間存放存活對象。

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

堆內存分代模型圖

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

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

（1）年輕代空間

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

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

三個區的默認比例是8:1:1，可以通過配置參數調整比例。

年輕代回收發起Minor GC（YongGC），當Eden內存區域被佔滿之後就發起GC，短暫的STW，基於垃圾收集器。

（2）老年代空間

是堆內存中最大的空間，，裏面的對象都是比較穩定或者老頑固，GC頻率不會頻繁執行。

老年代對象：

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

老年代回收發起Major GC / FULL GC，當老年代滿時會觸發MajorGC，通常至少經歷過一次Minor GC，再緊接着進行Major GC， Major GC清理Tenured區，用於回收老年代（CMS才能單獨清理）。

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

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

Full GC觸發條件：

老年代空間不足。
元空間不足擴容導致。
程序代碼執行System.gc時可能會執行。
當程序創建一個大對象時，Eden區域放不下大對象，老年代內存擔保分配，老年代也不足空間時。
年輕代存留對象晉升老年代時，老年代空間不足時。

2.2.5 Java對象內存分配過程

對象的分配過程

編譯器通過逃逸分析優化手段，確定對象是否在棧上分配還是堆上分配。
如果在堆上分配，則確定是否大對象，如果是則直接進入老年代空間分配，不然則走3。
對比tlab，如果tlab_top + size <= tlab_end，則在tlab上直接分配，並且增加tlab_top值，如果tlab不足以空間放當前對象，則重新申請一個tlab嘗試放入當前對象，如果還是不行則往下走4。
分配在Eden空間，當eden空間不足時發生YGC，倖存者區是否年齡晉升、動態年齡、老年代剩餘空間不足發生Full GC 。
當YGC之後仍然不足當前對象放入，則直接分配老年代。

TLAB作用原理：Java在內存新生代Eden區域開闢了一小塊線程私有區域，這塊區域爲TLAB，默認佔Eden區域大小的1%，作用於小對象，因爲小對象用完即丟，不存在線程共享，快速消亡GC，JVM優先將小對象分配在TLAB是線程私有的，所以沒有鎖的開銷，效率高，每次只需要線程在自己的緩衝區分配即可，不需要進行鎖同步堆。

對象除了基本類型的不一定是在堆內存分配，在JVM擁有逃逸分析，能夠分析出一個新的對象所擁有的範圍，從而決定是否要將這個對象分配到堆上，是JVM的默認行爲；Java 逃逸分析是一種優化技術，可以通過分析 Java 對象的作用域和生命週期，確定對象的內存分配位置和生命週期，從而減少不必要的內存分配和垃圾回收。可以在棧上分配，可以在棧幀上創建和銷燬，分離對象或標量替換，同步消除。

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收集器採用複製算法，作用在年輕代的一款垃圾收集器，串行運行，執行過程中會STW，是使用單個線程進行垃圾回收，響應速度優先。

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

使用場景：適合內存小几十兆以內，比較適合簡單的服務或者單CPU服務，避免了線程交互的開銷。
優點：小堆內存且單核CPU執行效率高。
缺點：堆內存大，多核CPU不適合，回收時長非常長。

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

Parallel Scavenge垃圾收集器採用了複製算法，作用在年輕代的一款垃圾收集器，是並行的多線程運行，執行過程中會發生STW，關注與程序吞吐量。

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

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

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

使用場景：適用於內存在幾個G之間，適用於後臺計算服務或者不需要太多交互的服務，保證吞吐量的服務。
優點：可控吞吐量、保證吞吐量，並行收集。
缺點：回收期間STW，隨着堆內存增大，回收暫停時間增大。

（3）Par New垃圾收集器

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

使用場景：搭配CMS使用

（4）CMS垃圾收集器

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

CMS分段

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

三色標記

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

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

三色標記算法的問題場景：當業務線程做了對象引用變更，會發生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;
        // 業務線程發生了引用改變， 原本r.a.b的引用置爲null
        r.a.b = null;
        // GC線程回來繼續上次掃描，發現r.a.b無引用，則認爲b對象無任何引用清除
        r.b = b;
        // GC 回收了b， 業務線程無法使用b
    }
}
 
class R {
    A a;
    B b;
}
 
class A {
    B b;
}
 
class B {
}

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

CMS基於這種錯誤標記的解決方案是採取寫屏障 + 增量更新Incremental Update ，在業務線程發生對象變化時，重新將R標識爲灰色，重新掃描一遍，Incremental Update 在特殊場景下還是會產生漏標。

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

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

使用場景：適用於互聯網或者 B/S服務，響應速度優先，適合6G左右。
優點：併發收集，低停頓，回收過程中最耗時的是併發標記和併發清除，它都能與用戶線程保持一起工作。
缺點：

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

無法處理浮動垃圾，在併發清理階段用戶線程還是在運行，這時候產生的新垃圾無法在這次當中處理，只有等待下次纔會清理。

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

因爲收集器是基於標記清除算法實現的，所以在收集器回收結束後，內存會產生碎片化，當碎片化非常嚴重的時候，這時候有大對象進入無法分配內存時會觸發FullGC，特殊場景下會使用Serial收集器，導致停頓不可控。

（5）G1垃圾收集器

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

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

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

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

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

CardTable：記錄每一塊card內存區域是否dirty，如果在發生YGC時，怎麼知道那些是存活對象，並且其它代區域有沒有引用這部分對象，於是把內存劃分了很多card區域，每個區域大小不超過512b，當該card區域裏的對象有引用關係，將當前card置爲“dirty”，並且使用卡表（CardTable）來記錄每一塊card是否dirty，在進行GC時，不用遍歷所有的空間，只需要遍歷卡表中爲"dirty"或者說布爾符合條件的card區域進行回掃。

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

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

RSet和卡表的區別是什麼？

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

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

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

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

使用場景：響應速度優先，較高的吞吐量，面向服務端，使用內存6G以上。
優點：並行與併發收集，分代分區收集，優先垃圾收集，空間整合，可控或者可預測停頓時間。
缺點：

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

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

G1對於Full GC是沒有處理流程，一旦發生Full GC G1的回收執行的是單線程的Serial回收器進行回收。

2.2.7 垃圾收集器配置使用

機器配置：64位 4C8G

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

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

CMS 跟 parNew佔比情況，默認下 ParNew佔用整個堆的空間爲：機器位數 * CPU核數 * 13 /10 ，當前機器配置計算得出 64 * 4 * 13 / 10 = 332M ，與圖上數值差別不大。

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

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

G1 新老年代的佔比是動態調整，隨着運行時根據實際情況劃分空間。

Java8默認ParallerGC收集器初始內存劃分情況：

parallel GC回收器默認堆old區與young區內存大小比例 2：1，圖上數值差別不大。

三、內存診斷實踐

3.1 內存快照生成

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

-XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=${filePath} 參數

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

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

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

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

引用：Arthas 命令列表

3.2 dump內存快照分析

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

用例 jhat E:\diydump\Java_pid2680.hprof

All classes including platform：列舉應用程序中所有類的信息，並快速定位內存問題。
Show all members of the rootset：顯示堆內存中所有根對象的信息，包括系統對象、靜態對象、本地對象等。
Show instance counts for all classes (including platform)：顯示所有類的實例數量。
Show heap histogram：顯示程序堆內存的直方圖，可以知道每個類的實例數量和佔用內存大小等信息，快速知道內存泄漏原因。

（2）jvisualvm也是Java 開發工具包裏自帶的一款圖形化工具，可以用於監控和診斷Java應用程序的性能問題。使用它可以實時查看Java 應用程序的內存使用情況、CPU使用情況、線程情況等，並可以進行內存分析、CPU分析、線程分析等內容。

以Java_pid2680.hprof爲例，進行內存分析內存泄漏原因：

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

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

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

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

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

四、總結

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

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

Java 8 內存管理原理解析及內存故障排查實踐

一、背景

二、Java 8 的內存管理

2.1 JVM（Java虛擬機）內存劃分

2.2 堆內存管理

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

2.2.2 GC Roots的概念和對象類型

2.2.3 垃圾對象回收算法

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

2.2.5 Java對象內存分配過程

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

2.2.7 垃圾收集器配置使用

三、內存診斷實踐

3.1 內存快照生成

3.2 dump內存快照分析

四、總結

揭露 FileSystem 引起的線上 JVM 內存溢出問題

首屆 AIGC 創新賽報名火熱進行中，67萬現金獎池等你來！

擁抱開源，擁抱未來 | vivo 積極支持並參與 The 2nd OSPO Summit

Redis Pipelining 底層原理分析及實踐

vivo 消息中間件測試環境項目多版本實踐

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結