JVM學習-自動記憶體管理

橡皮筋兒發表於2024-01-16
JVM記憶體

文章原文：https://gaoyubo.cn/blogs/6997cf1f.html

一、執行時資料區

Java虛擬機器在執行Java程式的過程中會把它所管理的記憶體劃分為若干個不同的資料區域。這些區域 有各自的用途，以及建立和銷燬的時間，有的區域隨著虛擬機器程式的啟動而一直存在，有些區域則是 依賴使用者執行緒的啟動和結束而建立和銷燬。根據《Java虛擬機器規範》的規定，Java虛擬機器所管理的記憶體將會包括以下幾個執行時資料區域

image-20231029140510184 image-20231029233012225

1.1程式計數器

執行緒私有

是一個非常小的記憶體區域，用於儲存當前執行緒正在執行的位元組碼指令的地址。每個執行緒在JVM中都有一個獨立的程式計數器。當JVM執行一條位元組碼指令時，程式計數器會更新為下一條指令的地址。

簡而言之，程式計數器儲存的是當前正在執行的位元組碼指令的地址。一旦這條指令執行完畢，程式計數器會立即更新為下一條指令的地址。這樣，JVM就可以知道接下來應該執行哪條指令。

需要注意的是，對於那些會導致控制流跳轉的指令（如條件跳轉、迴圈等），程式計數器會根據指令的具體行為更新為相應的目標地址，而不是簡單地遞增到下一個地址。

  • 執行 Java 方法和 native 方法時的區別：
    • 執行 Java 方法時：記錄虛擬機器正在執行的位元組碼指令地址；
    • 執行 native 方法時：空（Undefined）；
  • 是 5 個區域中唯一不會出現 OOM 的區域。

1.2虛擬機器棧

image-20231029233100723

執行緒私有

每個方法被執行的時候，Java虛擬機器都 會同步建立一個棧幀用於儲存區域性變數表、運算元棧、動態連線、方法出口等資訊。

  • 服務於 Java 方法；
  • 可能丟擲的異常：
    • OutOfMemoryError（在虛擬機器棧可以動態擴充套件的情況下，擴充套件時無法申請到足夠的記憶體）；
    • StackOverflowError（執行緒請求的棧深度 > 虛擬機器所允許的深度）；
  • 虛擬機器引數設定：-Xss.

區域性變數表存放了編譯期可知的各種Java虛擬機器基本資料型別（boolean、byte、char、short、int、 float、long、double）、物件引用。

1.3本地方法棧

執行緒私有

  • 服務於 native 方法；
  • 可能丟擲的異常：與 Java 虛擬機器棧一樣。

1.4堆

image-20231029233145284

執行緒共享

“幾乎”所有的物件例項都在這裡分配記憶體

由於即時編 譯技術的進步，尤其是逃逸分析技術的日漸強大，棧上分配、標量替換最佳化手段已經導致一些微妙 的變化悄然發生，所以說Java物件例項都分配在堆上也漸漸變得不是那麼絕對了。

  • 唯一的目的：存放物件例項；
  • 垃圾收集器管理的主要區域；
  • 可以處於物理上不連續的記憶體空間中；
  • 可能丟擲的異常：
    • OutOfMemoryError（堆中沒有記憶體可以分配給新建立的例項，並且堆也無法再繼續擴充套件了）。
  • 虛擬機器引數設定：
    • 最大值：-Xmx
    • 最小值：-Xms
    • 兩個引數設定成相同的值可避免堆自動擴充套件。

1.5方法區

常量池

執行緒共享

  • 儲存已被虛擬機器載入的類資訊、常量、靜態變數、即時編譯器編譯後的程式碼等資料；
    • 類資訊：即 Class 類，如類名、訪問修飾符、常量池、欄位描述、方法描述等。
  • 垃圾收集行為在此區域很少發生；
    • 不過也不能不清理，對於經常動態生成大量 Class 的應用，如 Spring 等，需要特別注意類的回收狀況。
  • 可能丟擲的異常：
    • OutOfMemoryError（方法區無法滿足記憶體分配需求時）。
  • JDK8之前：方法區稱呼為永久代
  • JDK8以後：廢棄了永久代的概念，改用與JRockit、J9一樣在本地記憶體中實現的元空間

方法區的型別資訊、靜態變數<------>class檔案的相對應的表

方法區的執行時常量池<---------->class的常量池表

執行時常量

執行時常量池也是方法區的一部分；

執行時常量池相對於Class檔案常量池的另外一個重要特徵是具備動態性，Java語言並不要求常量一定只有編譯期才能產生，也就是說，並非預置入Class檔案中常量池的內容才能進入方法區執行時常量池，執行期間也可以將新的常量放入池中，這種特性被開發人員利用得比較多的便是String類的 intern()方法。

Class 檔案中除了有類的版本、欄位、方法、介面等描述資訊外，還有一項是常量池，用於存放編譯器生成的各種字面量（就是程式碼中定義的 static final 常量）和符號引用，這部分資訊就儲存在執行時常量池中。

Class檔案不會儲存各個方法和欄位的最終記憶體佈局資訊，而是在將類載入到JVM後進行動態連結的，需要將欄位、方法的符號引用經過執行期轉換才能正常使用；

1.6 直接記憶體

  • 直接記憶體不是虛擬機器執行時資料區的一部分，也不是《Java虛擬機器規範》中定義的記憶體區域
  • 直接記憶體是在Java堆外的、直接向系統申請的記憶體空間
  • 來源於NIO，透過存在堆中的DirectByteBuffer操作Native記憶體
  • 通常，訪問直接記憶體的速度會優於Java堆，即讀寫效能高。因此處於效能考慮，讀寫頻繁的場合可能會考慮使用直接記憶體。Java的NIO庫允許Java程式使用直接記憶體，用於資料緩衝區
image-20231029143742474 image-20231029143859646

由於直接記憶體在Java堆外，因此它的大小不會直接受限於-Xmx指定的最大堆大小，但是系統記憶體是有限的，Java堆和直接記憶體的總和依然受限於作業系統能給出的最大記憶體

缺點

  • 分配回收成本較高
  • 不受JVM記憶體回收管理

直接記憶體大小可以透過MaxDirectMemorySize設定；如果不指定，預設與堆的最大值-Xmx引數值一致

參考：JVM系列（九）直接記憶體（Direct Memory） - 掘金 (juejin.cn)

二、HotSpot虛擬機器物件

2.1物件的建立

當Java虛擬機器遇到一條位元組碼new指令時。

  1. 首先將去檢查這個指令的引數是否能在常量池中定位到一個類的符號引用，
  2. 並且檢查這個符號引用代表的類是否已被載入、解析和初始化過。如果沒有，那必須先執行相應的類載入過程
  3. 在堆中將為新生物件分配記憶體 記憶體分配策略
  4. 記憶體空間（但不包括物件頭）都初始化為零值
  5. 物件頭設定：是哪個類的例項、如何才能找到類的後設資料資訊、雜湊碼、GC分代年齡
  6. 從虛擬機器的視角來看，一個新的物件已經產生了。
  7. 從Java程式的視角看來，Class檔案中的<init>()方法還沒有執行，執行構造方法。

這其中有兩個問題，

  1. 如何為物件記憶體劃分空間
  2. 如何保證建立記憶體時，劃分記憶體執行緒安全

劃分可用的記憶體

  • 指標碰撞（記憶體分配規整）
    • 用過的記憶體放一邊，沒用過的記憶體放一邊，中間用一個指標分隔；
    • 分配記憶體的過程就是將指標向沒用過的記憶體那邊移動所需的長度；
image-20231029232645062
  • 空閒列表（記憶體分配不規整）
    • 維護一個列表，記錄哪些記憶體塊是可用的；
    • 分配記憶體時，從列表上選取一塊足夠大的空間分給物件，並更新列表上的記錄；

劃分記憶體的指標的同步問題

  • 對分配記憶體空間的動作進行同步處理（CAS）；
  • 把記憶體分配動作按照執行緒劃分在不同的空間之中進行；
    • 每個執行緒在 Java 堆中預先分配一小塊記憶體，稱為本地執行緒分配緩衝（Thread Local Allocation Buffer，TLAB）；
    • 哪個執行緒要分配記憶體就在哪個執行緒的 TLAB 上分配，TLAB 用完需要分配新的 TLAB 時，才需要同步鎖定；
    • 透過 -XX:+/-UseTLAB 引數設定是否使用 TLAB。

2.2物件的記憶體佈局

物件在堆記憶體中的儲存佈局可以劃分為三個部分：
物件頭(Header)、例項資料(Instance Data)和對齊填充(Padding)。

image-20231029150149170 image-20231029150309158
  • 物件頭：
    • 第一部分(Mark Word)：雜湊碼（HashCode）、GC分代年齡、偏向狀態、鎖狀態標誌、偏向執行緒ID、偏向時間戳等資訊。
    • 第二部分：型別指標，指向它的類後設資料的指標，虛擬機器透過這個指標來判斷這個物件是哪個類的例項（HotSpot 採用的是直接指標的方式訪問物件的）；
    • 如果是個陣列物件，物件頭中還有一塊用於記錄陣列長度的資料。
  • 例項資料：
    • 預設分配順序：longs/doubles、ints、shorts/chars、bytes/booleans、oops (Ordinary Object Pointers)，相同寬度的欄位會被分配在一起，除了 oops，其他的長度由長到短；
    • 預設分配順序下，父類欄位會被分配在子類欄位前面。
  • 填充資料：
    • HotSpot VM要求物件的起始地址必須是8位元組的整數倍，所以不夠要補齊。

2.3物件的訪問定位

Java 程式需要透過虛擬機器棧上的 reference 資料來操作堆上的具體物件，reference 資料是一個指向物件的引用，不過如何透過這個引用定位到具體的物件，目前主要有以下兩種訪問方式：控制程式碼訪問和直接指標訪問。

控制程式碼訪問

控制程式碼訪問會在 Java 堆中劃分一塊記憶體作為控制程式碼池，每一個控制程式碼存放著到物件例項資料和物件型別資料的指標。

優勢：物件移動的時候（這在垃圾回收時十分常見）只需改變控制程式碼池中物件例項資料的指標，不需要修改reference本身。

image-20231029155643690

直接指標訪問

直接指標訪問方式在 Java 堆物件的例項資料中存放了一個指向物件型別資料的指標，在 HotSpot 中，這個指標會被存放在物件頭中。

優勢：減少了一次指標定位物件例項資料的開銷，速度更快。

image-20231029155746893

三、OOM 異常

3.1Java 堆溢位

  • 出現標誌：java.lang.OutOfMemoryError: Java heap space
  • 解決方法：
    • 先透過記憶體映像分析工具分析 Dump 出來的堆轉儲快照，確認記憶體中的物件是否是必要的，即分清楚是出現了記憶體洩漏還是記憶體溢位；
    • 如果是記憶體洩漏，透過工具檢視洩漏物件到 GC Root 的引用鏈，定位出洩漏的位置；
    • 如果不存在洩漏，檢查虛擬機器堆引數（-Xmx 和 -Xms）是否可以調大，檢查程式碼中是否有哪些物件的生命週期過長，嘗試減少程式執行期的記憶體消耗。
  • 虛擬機器引數：
    • -XX:HeapDumpOnOutOfMemoryError：讓虛擬機器在出現記憶體洩漏異常時 Dump 出當前的記憶體堆轉儲快照用於事後分析。

3.2Java 虛擬機器棧和本地方法棧溢位

  • 單執行緒下，棧幀過大、虛擬機器容量過小都不會導致 OutOfMemoryError，只會導致 StackOverflowError（棧會比記憶體先爆掉），一般多執行緒才會出現 OutOfMemoryError，因為執行緒本身要佔用記憶體；
  • 如果是多執行緒導致的 OutOfMemoryError，在不能減少執行緒數或更換 64 位虛擬機器的情況，只能透過減少最大堆和減少棧容量來換取更多的執行緒；
    • 這個調節思路和 Java 堆出現 OOM 正好相反，Java 堆出現 OOM 要調大堆記憶體的設定值，而棧出現 OOM 反而要調小。

3.3方法區和執行時常量池溢位

  • 測試思路：產生大量的類去填滿方法區，直到溢位；
  • 在經常動態生成大量 Class 的應用中，如 Spring 框架（使用 CGLib 位元組碼技術），方法區溢位是一種常見的記憶體溢位，要特別注意類的回收狀況。

3.4直接記憶體溢位

  • 出現特徵：Heap Dump 檔案中看不見明顯異常，程式中直接或間接用了 NIO；
  • 虛擬機器引數：-XX:MaxDirectMemorySize，如果不指定，則和 -Xmx 一樣。

四、垃圾收集

垃圾收集（Garbage Collection，GC），它的任務是解決以下 3 件問題：

  • 哪些記憶體需要回收？
  • 什麼時候回收？
  • 如何回收？

其中第一個問題很好回答，在 Java 中，GC 主要發生在 Java 堆和方法區中，對於後兩個問題，將在之後的內容中進行討論，並介紹 HotSpot 的 7 個垃圾收集器。

4.1判斷物件的生死

JVM學習-自動記憶體管理

什麼時候回收物件？當然是這個物件再也不會被用到的時候回收。

所以要想解決 “什麼時候回收？” 這個問題，我們要先能判斷一個物件什麼時候什麼時候真正的 “死” 掉了，判斷物件是否可用主要有以下兩種方法。

4.1.1判斷物件是否可用的演算法

引用計數演算法

  • 演算法描述：
    • 給物件新增一個引用計數器；
    • 每有一個地方引用它，計數器加 1；
    • 引用失效時，計數器減 1；
    • 計數器值為 0 的物件不再可用。
  • 缺點：
    • 很難解決迴圈引用的問題。即 objA.instance = objB; objB.instance = objA;，objA 和 objB 都不會再被訪問後，它們仍然相互引用著對方，所以它們的引用計數器不為 0，將永遠不能被判為不可用。

可達性分析演算法（主流）

image-20231029233255061
  • 演算法描述：
    • 從 "GC Root" 物件作為起點開始向下搜尋，走過的路徑稱為引用鏈（Reference Chain）；
    • 從 "GC Root" 開始，不可達的物件被判為不可用。
  • Java 中可作為 “GC Root” 的物件：
    • 棧中（本地變數表中的reference）
      • 虛擬機器棧中，棧幀中的本地變數表引用的物件；
      • 本地方法棧中，JNI 引用的物件（native方法）；
    • 方法區中
      • 類的靜態屬性引用的物件；
      • 常量引用的物件；

即便如此，一個物件也不是一旦被判為不可達，就立即死去的，宣告一個的死亡需要經過兩次標記過程。

併發情況的可達性分析

在可達性分析中，第一階段 ”根節點列舉“ 是必須 STW 的，那麼為什麼因此必須在一個能保障一致性的快照上才能進行物件圖的遍歷，而不是同步使用者執行緒進行呢？

引入三色標記作為工具來輔助推導，把遍歷物件圖過程中遇到的物件，按照“是否訪問過”這個條件標記成以下三種顏色：

  • 白色：表示物件尚未被垃圾收集器訪問過。顯然在可達性分析剛剛開始的階段，所有的物件都是白色的，若在分析結束的階段，仍然是白色的物件，即代表不可達。
  • 黑色：表示物件已經被垃圾收集器訪問過，且這個物件的所有引用都已經掃描過。黑色的物件代 表已經掃描過，它是安全存活的，如果有其他物件引用指向了黑色物件，無須重新掃描一遍。黑色對 象不可能直接（不經過灰色物件）指向某個白色物件。
  • 灰色：表示物件已經被垃圾收集器訪問過，但這個物件上至少存在一個引用還沒有被掃描過。
image-20231029215916416

關於可達性分析的掃描過程，可以看作物件圖上一股以灰色為波峰的波紋從黑向白推進的過程，此時如果使用者執行緒改變了物件的引用關係，會發生兩種情況：

  • 一種是把原本消亡的物件錯誤標記為存活， 這下次收集清理掉就好。
  • 另一種是把原本存活的物件錯誤標記為已消亡，那麼可能會導致程式崩潰。
image-20231029220102915

如上圖所示，b -> c 的引用被切斷，但同時使用者執行緒建立了一個新的從 a -> c 的引用，由於已經遍歷到了 b，不可能再回去遍歷 a（黑色物件不會被重新掃描），再遍歷 c，所以這個 c 實際是存活的物件，但由於沒有被垃圾收集器掃描到，被錯誤地標記成了白色，就會導致c被標記為需要回收的物件。

總結下物件消失問題的兩個條件：

  1. 插入了一條或多條從黑色物件到白色物件的新引用
  2. 刪除了全部從灰色物件到該白色物件的直接或間接引用

當且僅當以上兩個條件同時滿足時，才會產生 “物件消失” 的問題，即原本應該是黑色的物件被誤標為白色

兩種解決方案
  1. 增量更新（Incremental Update）：增量更新破壞的是第一個條件，當黑色物件插入新的指向白色物件的引用關係時（就是上圖中的 a -> c 引用關係），就將這個新插入的引用記錄下來，等併發掃描結束之後，再將這些記錄過的引用關係中的黑色物件（a）為根，重新掃描一次。這可以簡化理解為，黑色物件一旦新插入了指向白色物件的引用之後，它就變回灰色物件了。
  2. 原始快照（Snapshot At The Beginning，SATB）：原始快照要破壞的是第二個條件，當灰色物件要刪除指向白色物件的引用關係時（上圖中的 b -> c 引用關係），就將這個要刪除的引用記錄下來，在併發掃描結束之後，再將這些記錄過的引用關係中的灰色物件（b）為根，重新掃描一次。這也可以簡化理解為，無論引用關係刪除與否，都會按照剛剛開始掃描那一刻的物件圖快照來進行搜尋。

對引用關係記錄的插入還是刪除，虛擬機器的記錄操作都是透過寫屏障現的。在 HotSpot虛擬機器中，增量更新和原始快照這兩種解決方案都有實際應用，譬如，CMS是基於增量更新 來做併發標記的，G1、Shenandoah則是用原始快照來實現。

4.1.2四種引用型別

JDK 1.2 後，Java 中才有了後 3 種引用的實現。

  • 強引用： 像 Object obj = new Object() 這種，只要強引用還存在，垃圾收集器就永遠不會回收掉被引用的物件。
  • 軟引用： 用來引用還存在但非必須的物件。對於軟引用物件，在 OOM 前，虛擬機器會把這些物件列入回收範圍中進行第二次回收，如果這次回收後，記憶體還是不夠用，就 OOM。實現類：SoftReference。
  • 弱引用： 被弱引用引用的物件只能生存到下一次垃圾收集前，一旦發生垃圾收集，被弱引用所引用的物件就會被清掉。實現類：WeakReference。
  • 虛引用： 幽靈引用，對物件沒有半毛錢影響，甚至不能用來取得一個物件的例項。它唯一的用途就是：當被一個虛引用引用的物件被回收時，系統會收到這個物件被回收了的通知。實現類：PhantomReference。

4.1.3死亡的兩次標記過程

  • 當發現物件不可達後，該物件被第一次標記，並進行是否有必要執行 finalize() 方法的判斷；
    • 不需要執行：物件沒有覆蓋 finalize() 方法，或者 finalize() 方法已被執行過（finalize() 只被執行一次）；
    • 需要執行：將該物件放置在一個佇列中，稍後由一個虛擬機器自動建立的低優先順序執行緒執行。
  • finalize() 方法是物件逃脫死亡的最後一次機會，不過虛擬機器不保證等待 finalize() 方法執行結束，也就是說，虛擬機器只觸發 finalize() 方法的執行，如果這個方法要執行超久，那麼虛擬機器並不等待它執行結束，所以最好不要用這個方法。
  • finalize() 方法能做的，try-finally 都能做，所以忘了這個方法吧

4.1.4方法區的回收

永久代的 GC 主要回收：廢棄常量 和 無用的類。

  • 廢棄常量：例如一個字串 "abc"，當沒有任何引用指向 "abc" 時，它就是廢棄常量了。
  • 無用的類：同時滿足以下 3 個條件的類。
    • 該類的所有例項已被回收，Java 堆中不存在該類的任何例項；
    • 載入該類的 Classloader 已被回收；
    • 該類的 Class 物件沒有被任何地方引用，即無法在任何地方透過反射訪問該類的方法。

4.2垃圾收集演算法

image-20231029204343997

4.2.1標記 - 清除演算法

  • 演算法描述：

    • 先標記出所有需要回收的物件（圖中深色區域）；
    • 標記完後，統一回收所有被標記物件（留下狗啃似的可用記憶體區域……）。

  • 不足：

    • 效率問題：標記和清理兩個過程的效率都不高。
    • 空間碎片問題：標記清除後會產生大量不連續的記憶體碎片，導致以後為較大的物件分配記憶體時找不到足夠的連續記憶體，會提前觸發另一次 GC。
    image-20231029204413509

4.2.2標記 - 複製演算法

  • 演算法描述：

    • 將可用記憶體分為大小相等的兩塊，每次只使用其中一塊；
    • 當一塊記憶體用完時，將這塊記憶體上還存活的物件複製到另一塊記憶體上去，將這一塊記憶體全部清理掉。

  • 不足： 可用記憶體縮小為原來的一半，適合GC過後只有少量物件存活的新生代。

  • 節省記憶體的方法：

    • 新生代中的物件 98% 都是朝生夕死的，所以不需要按照 1:1 的比例對記憶體進行劃分；
    • 把記憶體劃分為：
      • 1 塊比較大的 Eden 區；
      • 2 塊較小的 Survivor 區；
    • 每次使用 Eden 區和 1 塊 Survivor 區；
    • 回收時，將以上 2 部分割槽域中的存活物件複製到另一塊 Survivor 區中，然後將以上兩部分割槽域清空；
    • JVM 引數設定：-XX:SurvivorRatio=8 表示 Eden 區大小 / 1 塊 Survivor 區大小 = 8。
    image-20231029204510517

4.2.3標記 - 整理演算法

  • 演算法描述：
    • 標記方法與 “標記 - 清除演算法” 一樣；
    • 標記完後，將所有存活物件向一端移動，然後直接清理掉邊界以外的記憶體。
  • 不足： 存在效率問題，適合老年代。
image-20231029204836071

進化：分代收集演算法

  • 新生代： GC 過後只有少量物件存活 —— 複製演算法
  • 老年代： GC 過後物件存活率高 —— 標記 - 整理演算法

4.3HotSpot 中 GC 演算法的實現

image-20231029204934730

透過之前的分析，GC 演算法的實現流程簡單的來說分為以下兩步：

  1. 找到死掉的物件；
  2. 把它清了。

想要找到死掉的物件，我們就要進行可達性分析，也就是從 GC Root 找到引用鏈的這個操作，需要獲取所有物件引用。

那麼，首先要找到哪些是 GC Roots。

有兩種查詢 GC Roots 的方法：

  • 遍歷方法區和棧區查詢（保守式 GC）。
  • 透過OopMap資料結構來記錄 GC Roots 的位置（準確式 GC）。

很明顯，保守式 GC 的成本太高。準確式 GC 的優點就是能夠讓虛擬機器快速定位到 GC Roots。

但是當記憶體中的物件間的引用關係發生變化時，就需要改變 OopMap 中的相應內容。可是能導致引用關係發生變化的指令非常之多，如果我們執行完一條指令就改下 OopMap，這 GC 成本實在太高了。於此，安全點和安全區域就很重要了。

4.3.1安全點

因此，HotSpot 採用了一種在 “安全點” 更新 OopMap 的方法，安全點的選取既不能讓 GC 等待的時間過長，也不能過於頻繁增加執行負擔，也就是說，我們既要讓程式執行一段時間，又不能讓這個時間太長。

JVM 中每條指令執行的是很快的，所以一個超級長的指令流也可能很快就執行完了，所以 真正會出現 “長時間執行” 的一般是指令的複用，例如：方法呼叫、迴圈跳轉、異常跳轉等，虛擬機器一般會將這些地方設定為安全點更新 OopMap 並判斷是否需要進行 GC 操作。

此外，在進行列舉根節點的這個操作時，為了保證準確性，我們需要在一段時間內 “凍結” 整個應用，即 Stop The World，因為如果在我們分析可達性的過程中，物件的引用關係還在變來變去，那是不可能得到正確的分析結果的。即便是在號稱幾乎不會發生停頓的 CMS 垃圾收集器中，列舉根節點時也是必須要停頓的。這裡就涉及到了一個問題：

如何讓所有執行緒跑到最近的安全點再停頓下來進行 GC 操作呢？

主要有以下兩種方式：

  • 搶先式中斷：
    • 先中斷所有執行緒；
    • 發現有執行緒沒中斷在安全點，恢復它，讓它跑到安全點。
  • 主動式中斷： (主要使用)
    • 設定一箇中斷標記；
    • 每個執行緒到達安全點時，檢查這個中斷標記，選擇是否中斷自己。

4.3.2安全區域

除此安全點之外，還有一個叫做安全區域的東西。

安全區域是指在一段程式碼片段之中，引用關係不會發生變化，因此在這個區域中的任意位置開始 GC 都是安全的。

一個一直在執行的執行緒可以自己 “走” 到安全點去，可是一個處於 Sleep 或者 Blocked 狀態的執行緒是沒辦法自己到達安全點中斷自己的，我們總不能讓 GC 操作一直等著這些個 ”不執行“ 的執行緒重新被分配資源吧。對於這種情況，我們要依靠安全區域來解決。

當執行緒執行到安全區域時，它會把自己標識為 Safe Region，這樣 JVM 發起 GC 時是不會理會這個執行緒的。當這個執行緒要離開安全區域時，它會檢查系統是否在 GC 中，如果不在，它就繼續執行，如果在，它就等GC結束再繼續執行。

4.4 記憶集、卡表、寫屏障

記憶集

為解決物件跨代引用所帶來的問題，垃圾收集器在新生代中建立了名為記憶集（Remembered Set）的資料結構，用以避免把整個老年代加進GC Roots掃描範圍。

記憶集是一種用於記錄從非收集區域指向收集區域的指標集合的抽象資料結構。
收集器只需要透過記憶集判斷出某一塊非收集區域是否存在有指向了收集區域的指標就可以了。

採用種稱為卡表（Card Table）的方式去實現記憶集。

卡表

卡表最簡單的形式只是一個位元組陣列。

CARD_TABLE [this address >> 9] = 0;

位元組陣列CARD_TABLE的每一個元素都對應著其標識的記憶體區域中一塊特定大小的記憶體塊，這個 記憶體塊被稱作卡頁（Card Page）。

一般來說，卡頁大小都是以2的N次冪的位元組數，透過上面程式碼可 以看出HotSpot中使用的卡頁是2的9次冪，即512位元組（地址右移9位，相當於用地址除以512）。那如 果卡表標識記憶體區域的起始地址是0x0000的話，陣列CARD_TABLE的第0、1、2號元素，分別對應了 地址範圍為0x0000～0x01FF、0x0200～0x03FF、0x0400～0x05FF的卡頁記憶體塊

image-20231029213018820

一個卡頁的記憶體中通常包含不止一個物件，只要卡頁內有一個（或更多）物件的欄位存在著跨代 指標，那就將對應卡表的陣列元素的值標識為1，稱為這個元素變髒（Dirty），沒有則標識為0。

在垃圾收集發生時，只要篩選出卡表中變髒的元素，就能輕易得出哪些卡頁記憶體塊中包含跨代指標，把它 們加入GC Roots中一併掃描。

寫屏障

如何維護卡表元素？

如何維護卡表《=======》如何在物件賦值的那一刻去更新卡表

  • 解釋執行的位元組碼，好處理，虛擬機器負責每條位元組碼指令的執行，有充分的介入空間
  • 編譯執行的場景中經過即時編譯後的程式碼已經是純粹的機器指令流了，這就必須找到一個在機器碼層面的手段，把維護卡表的動作放到每一個賦值操作之中。

在HotSpot虛擬機器裡是透過寫屏障（Write Barrier）技術維護卡表狀態的。

寫屏障可以看作在虛擬機器層面對“引用型別欄位賦值”這個動作的AOP切面，在引用物件賦值時會產生一個環形（Around）通知供程式執行額外的動作。

在賦值前的部分的寫屏障叫作寫前屏障（Pre-Write Barrier）
在賦值 後的則叫作寫後屏障（Post-Write Barrier）

void oop_field_store(oop* field, oop new_value) {
	// 引用欄位賦值操作
	*field = new_value;
	// 寫後屏障，在這裡完成卡表狀態更新
	post_write_barrier(field, new_value);
}

偽共享問題

除了寫屏障的開銷外，卡表在高併發場景下還面臨著偽共享（False Sharing）問題。

偽共享是處 理併發底層細節時一種經常需要考慮的問題，現代中央處理器的快取系統中是以快取行（Cache Line） 為單位儲存的，當多執行緒修改互相獨立的變數時，如果這些變數恰好共享同一個快取行，就會彼此影響（寫回、無效化或者同步）而導致效能降低，這就是偽共享問題。

假設處理器的快取行大小為64位元組，由於一個卡表元素佔1個位元組，64個卡表元素將共享同一個緩 存行。這64個卡表元素對應的卡頁總的記憶體為32KB（64×512位元組），也就是說如果不同執行緒更新的對 象正好處於這32KB的記憶體區域內，就會導致更新卡表時正好寫入同一個快取行而影響效能。

為了避免偽共享問題，一種簡單的解決方案是不採用無條件的寫屏障，而是先檢查卡表標記，只有當該卡表元 素未被標記過時才將其標記為變髒，即將卡表更新的邏輯變為以下程式碼所示：

if (CARD_TABLE [this address >> 9] != 0)
{
	CARD_TABLE [this address >> 9] = 0;
}

在JDK 7之後，HotSpot虛擬機器增加了一個新的引數-XX：+UseCondCardMark，用來決定是否開啟卡表更新的條件判斷

4.5垃圾收集器

垃圾收集器就是記憶體回收操作的具體實現。有的屬於新生代收集器，有的屬於老年代收集器，所以一般是搭配使用的。

檢視垃圾收集器種類指令：java -XX:+PrintCommandLineFlags -version

image-20231029210826750

Serial / ParNew 搭配 Serial Old 收集器

image-20231029210903044

Serial 收集器是虛擬機器在 Client 模式下的預設新生代收集器，它的優勢是簡單高效，在單 CPU 模式下很牛。

ParNew 收集器就是 Serial 收集器的多執行緒版本，雖然除此之外沒什麼創新之處，但它卻是許多執行在 Server 模式下的虛擬機器中的首選新生代收集器，因為除了 Serial 收集器外，只有它能和 CMS 收集器搭配使用。

Parallel 搭配 Parallel Scavenge 收集器

它們的關注點與其他收集器不同，其他收集器關注於盡可能縮短垃圾收集時使用者執行緒的停頓時間，而 Parallel Scavenge 收集器的目的是達到一個可控的吞吐量。

吞吐量 = 執行使用者程式碼時間 / ( 執行使用者程式碼時間 + 垃圾收集時間 )

因此，Parallel Scavenge 收集器不管是新生代還是老年代都是多個執行緒同時進行垃圾收集，十分適合於應用在注重吞吐量以及 CPU 資源敏感的場合。

可調節的虛擬機器引數：

  • -XX:MaxGCPauseMillis：最大 GC 停頓的秒數；
  • -XX:GCTimeRatio：吞吐量大小，一個 0 ~ 100 的數，最大 GC 時間佔總時間的比率 = 1 / (GCTimeRatio + 1)；
  • -XX:+UseAdaptiveSizePolicy：一個開關引數，開啟後就無需手工指定 -Xmn，-XX:SurvivorRatio 等引數了，虛擬機器會根據當前系統的執行情況收集效能監控資訊，自行調整。

CMS 收集器

回收老年代

image-20231029211205554 image-20231029211216197

引數設定：

  • -XX:+UseCMSCompactAtFullCollection：在 CMS 要進行 Full GC 時進行記憶體碎片整理（預設開啟）
  • -XX:CMSFullGCsBeforeCompaction：在多少次 Full GC 後進行一次空間整理（預設是 0，即每一次 Full GC 後都進行一次空間整理）

關於 CMS 使用 標記 - 清除 演算法的一點思考：

之前對於 CMS 為什麼要採用 標記 - 清除 演算法十分的不理解，既然已經有了看起來更高階的 標記 - 整理 演算法，那 CMS 為什麼不用呢？

  1. 標記 - 整理 會將所有存活物件向一端移動，需要一個指標來維護這個分隔存活物件和無用空間的點，而CMS 是併發清理的，雖然我們啟動了多個執行緒進行垃圾回收，不過如果使用 標記 - 整理 演算法，為了保證執行緒安全，在整理時要對那個分隔指標加鎖，保證同一時刻只有一個執行緒能修改它，加鎖的這一過程相當於將並行的清理過程變成了序列的，也就失去了並行清理的意義了。
  2. CMS關注的是最短停頓時間，標記 - 清除演算法的Stop The World最小。

所以，CMS 採用了 標記 - 清除 演算法。

Garbage First(G1)收集器

image-20231029212015528 image-20231029212024404

在G1收集器出現之前的所有 其他收集器，包括CMS在內，垃圾收集的目標範圍要麼是整個新生代（Minor GC），要麼就是整個老年代（Major GC），再要麼就是整個Java堆（Full GC）。

而G1跳出了這個樊籠，它可以面向堆記憶體任何部分來組成回收集（Collection Set，一般簡稱CSet）進行回收，衡量標準不再是它屬於哪個分代，而是哪塊記憶體中存放的垃圾數量最多，回收收益最大，這就是G1收集器的Mixed GC模式。

Region佈局

G1不再堅持固定大小以及固定數量的 分代區域劃分，而是把連續的Java堆劃分為多個大小相等的獨立區域Region，每一個Region都可以 根據需要，扮演新生代的Eden空間、Survivor空間，或者老年代空間。

  • 大物件儲存區域：Region中還有一類特殊的Humongous區域，專門用來儲存大物件。G1認為只要大小超過了一個 Region容量一半的物件即可判定為大物件。
  • 引數設定：每個Region的大小可以透過引數-XX：G1HeapRegionSize設 定，取值範圍為1MB～32MB，且應為2的N次冪。
  • 超大物件儲存：對於那些超過了整個Region容量的超級大物件， 將會被存放在N個連續的Humongous Region之中，G1的大多數行為都把Humongous Region作為老年代 的一部分來進行看待
垃圾處理思路

具體的處理思路是讓G1收集器去跟蹤各個Region裡面的垃 圾堆積的“價值”大小，價值即回收所獲得的空間大小以及回收所需時間的經驗值，然後在後臺維護一 個優先順序列表，每次根據使用者設定允許的收集停頓時間（使用引數-XX：MaxGCPauseMillis指定，默 認值是200毫秒），優先處理回收價值收益最大的那些Region，這也就是“Garbage First”名字的由來。

難以解決的問題
  1. Region裡面存在的跨Region引用物件如何解決？

使用記憶集避免全堆作為GC Roots掃描，但在G1收集器上記 憶集的應用其實要複雜很多。

G1的記憶集在儲存結構的本質上是一種雜湊表，Key是別的Region的起始地址，Value是一個集合，裡面儲存的元素是卡表的索引號。這種“雙向”的卡表結構（卡表是“我指向誰”，這種結構還記錄了“誰指向我”）比原來的卡表實現起來更復雜

  1. 在併發標記階段如何保證收集執行緒與使用者執行緒互不干擾地執行

G1 收集器則是透過原始快照（SATB）演算法來實現的

此外，G1為每一個Region設 計了兩個名為TAMS（Top at Mark Start）的指標，把Region中的一部分空間劃分出來用於併發回收過 程中的新物件分配，併發回收時新分配的物件地址都必須要在這兩個指標位置以上。
G1收集器預設在這個地址以上的物件是被隱式標記過的，即預設它們是存活的，不納入回收範圍。

對比CMS收集器

  • 記憶體佔用：
    • G1的卡表實現更為複雜，每個Region都需要有一份卡表，無論其在新生代還是老年代中的角色。這可能導致G1的記憶集和其他記憶體消耗佔用整個堆容量的20%甚至更多的記憶體空間。
    • 相比之下，CMS的卡表相對簡單，只有一份，並且只需處理老年代到新生代的引用。這減少了卡表維護的開銷。
  • 執行負載：
    • 由於G1和CMS使用寫屏障，它們在程式執行時的負載會有所不同。
    • CMS使用寫後屏障來更新維護卡表。
    • G1除了使用寫後屏障進行卡表維護外，為了實現原始快照搜尋演算法，還需要使用寫前屏障來跟蹤併發時的指標變化。原始快照搜尋演算法減少了併發標記和重新標記階段的消耗，避免了CMS在最終標記階段停頓時間過長的缺點，但在使用者程式執行過程中會帶來額外的負擔。
  • 寫屏障實現：
    • 由於G1對寫屏障的複雜操作消耗更多的運算資源，CMS的寫屏障實現是直接的同步操作。
    • G1將寫屏障實現為類似於訊息佇列的結構，非同步處理佇列中的寫前屏障和寫後屏障任務。
  • 適用場景：
    • 在小記憶體應用上，CMS的效能可能仍然優於G1。
    • 在大記憶體應用上，G1通常能夠發揮其優勢，特別是在Java堆容量在6GB至8GB之間。

總體而言，對於選擇垃圾收集器，需要考慮具體的應用場景和需求，並透過實際測試來得出最合適的結論。隨著HotSpot對G1的不斷最佳化，G1在不同場景中的表現可能會持續改善。

目前在小記憶體應用上CMS的表現大機率仍然要會優於G1，而在大記憶體應用上G1則大多能發揮其優勢，這個優劣勢的Java堆容量平衡點通常在6GB至8GB之間，當然，以上這些也僅是經驗之談，不同應用需要量體裁衣地實際測試才能得出最合適的結論，隨著HotSpot的開發者對G1的不斷最佳化，也 會讓對比結果繼續向G1傾斜

里程碑

從G1開始，最先進的垃圾收集器的設計導向都不約而同地變為追求能夠應付應用的記憶體分配速率 （Allocation Rate），而不追求一次把整個Java堆全部清理乾淨。

這樣，應用在分配，同時收集器在收集，只要收集的速度能跟得上物件分配的速度，那一切就能運作得很完美。

這種新的收集器設計思路 從工程實現上看是從G1開始興起的，所以說G1是收集器技術發展的一個里程碑。

GC 日誌解讀

image-20231029212257717

低延遲收集器

Shenandoah和ZGC是兩種在Java平臺上開發的具有低停頓時間目標的垃圾收集器。它們的目標是減少長時間停頓（Full GC）的發生，以提高Java應用程式的響應性和效能。以下是關於Shenandoah和ZGC的一些關鍵特點：

Shenandoah Garbage Collector:

  1. 低停頓時間：Shenandoah的主要目標是實現非常低的停頓時間。它透過併發標記、併發標記-清除和併發整理等技術來降低垃圾收集期間的暫停時間。
  2. 適用範圍：Shenandoah適用於需要高度響應性的應用程式，例如線上事務處理系統，其中低延遲是至關重要的。
  3. 全域性併發：Shenandoah使用全域性併發的方式，意味著它在整個堆記憶體上工作，而不僅僅是一部分。這使得它可以在更大的堆記憶體上表現出色。
  4. Java版本：Shenandoah在Java 12中首次引入，是OpenJDK專案的一部分。

Z Garbage Collector (ZGC):

  1. 低停頓時間：ZGC的目標也是降低暫停時間。它透過併發標記、壓縮和垃圾回收來實現這一目標。
  2. 適用範圍：ZGC適用於需要低延遲和響應性的應用程式，特別是大記憶體應用，例如大資料處理。
  3. 全域性併發：類似於Shenandoah，ZGC也使用全域性併發，這使得它可以在大型堆上工作。
  4. Java版本：ZGC在Java 11中首次引入，也是OpenJDK專案的一部分。

這兩個垃圾收集器的共同目標是減少垃圾收集期間的停頓時間，使Java應用程式更具響應性。選擇哪個收集器取決於應用程式的具體需求和硬體環境。在Java 11及之後的版本中，開發者可以根據效能要求選擇Shenandoah或ZGC，以提高應用程式的效能和使用者體驗。

Epsilon垃圾收集器

Epsilon垃圾收集器是一種特殊的垃圾收集器，它在Java中引入了一種不進行垃圾收集的策略。Epsilon垃圾收集器實際上是一種"無操作"的垃圾收集器，它不會執行任何垃圾回收操作，而是允許堆記憶體不斷增長，直到達到作業系統的限制。

Epsilon垃圾收集器的設計目標是用於某些特殊用途，例如：

  1. 效能測試和基準測試：Epsilon垃圾收集器可以用於執行效能測試和基準測試，其中不希望垃圾收集引入額外的效能變化。
  2. 短暫的、生命週期較短的應用程式：對於某些應用程式，例如一次性命令列工具或短暫執行的應用程式，Epsilon垃圾收集器可以作為一種輕量級的選擇，避免了垃圾收集器的啟動和停頓。
  3. 堆外記憶體管理：Epsilon垃圾收集器還可以用於管理堆外記憶體，這是一種不受垃圾收集器管理的記憶體，適用於一些特殊用途。

Epsilon垃圾收集器並不適用於大多數常規Java應用程式，因為它不會回收堆記憶體中的垃圾，這可能導致記憶體洩漏。它適用於那些確切瞭解自己的應用程式行為並且明確知道不需要垃圾收集的情況。

Epsilon垃圾收集器是Java 11中引入的，可以透過命令列引數 -XX:+UseEpsilonGC 啟用。但大多數Java應用程式仍然使用其他垃圾收集器，例如G1、ZGC或Shenandoah，以滿足它們的垃圾收集需求。

收集器的權衡

出發點

應用程式的主要關注點是什麼？

如果是資料分析、科學計算類的任務，目標是能儘快算出結果， 那吞吐量就是主要關注點；

如果是SLA應用，那停頓時間直接影響服務質量，嚴重的甚至會導致事務超時，這樣延遲就是主要關注點；而如果是客戶端應用或者嵌入式應用，那垃圾收集的記憶體佔用則是不可忽視的。

SLA（Service Level Agreement，服務級別協議）應用通常是指在服務提供者和服務使用者之間制定和遵守的一種協議，其中規定了服務的質量、效能、可用性等方面的標準和承諾。SLA應用通常與服務提供者和客戶之間的服務交付和接受有關，特別是在雲端計算、網路服務、託管服務和其他IT服務領域。

以下是一些SLA應用的示例：

  1. 雲服務提供商：雲服務提供商通常與客戶簽訂SLA，以規定雲端計算服務的效能、可用性、資料備份、安全性等方面的承諾。如果雲服務提供商未能滿足SLA中的承諾，可能需要提供賠償或補償。
  2. 網路服務：網路服務提供商通常與企業客戶簽訂SLA，以規定網路連線的可用性、頻寬、延遲等方面的服務質量。SLA可用於確保網路服務符合業務需求。
  3. 託管服務：託管服務提供商通常與客戶簽訂SLA，以規定託管服務的效能、可用性、安全性和資料備份等方面的標準。這有助於確保託管的應用程式和資料的可靠性。
  4. 電子商務：線上商店和電子商務平臺可能與物流服務提供商簽訂SLA，以確保訂單交付的時間和質量達到一定標準。
  5. 移動應用程式和遊戲：開發者和移動應用程式平臺或遊戲服務提供商之間可以簽訂SLA，以規定應用程式或遊戲的效能、穩定性和可用性。

執行應用的基礎設施如何？

譬如硬體規格，要涉及的系統架構是x86-32/64、SPARC還是 ARM/Aarch64；

處理器的數量多少，分配記憶體的大小；選擇的作業系統是Linux、Solaris還是Windows 等

使用JDK的發行商是什麼？版本號是多少？

是ZingJDK/Zulu、OracleJDK、Open-JDK、OpenJ9或是其他公司的發行版？
該JDK對應了《Java虛擬機器規範》的哪個版本？

選擇

一般來說，收集器的選擇就從以上這幾點出發來考慮。舉個例子，假設某個直接面向使用者提供服 務的B/S系統準備選擇垃圾收集器，一般來說延遲時間是這類應用的主要關注點，那麼：

C4

如果有充足的預算但沒有太多調優經驗，那麼一套帶商業技術支援的專有硬體或者軟體解決方案是不錯的選擇，Azul公司以前主推的Vega系統和現在主推的Zing VM是這方面的代表，這樣你就可以使用傳說中的C4收集器了。

C4（Continuous Concurrent Compacting Collector）是一種用於Java虛擬機器（JVM）的垃圾收集器，它專注於降低垃圾收集引起的停頓時間。C4收集器的目標是在減少停頓時間的同時提供高吞吐量和良好的效能。它是以低停頓時間為特色的垃圾收集器。

以下是C4垃圾收集器的一些關鍵特點：

  1. 低停頓時間：C4收集器的設計目標是實現極低的停頓時間。它透過併發標記、併發標記-清除和併發整理等技術，使垃圾收集的大部分工作在應用程式執行時進行，從而降低了停頓時間。
  2. 適用範圍：C4收集器適用於需要快速響應和低延遲的應用程式，如線上事務處理系統、Web應用程式和其他對停頓時間要求較高的應用。
  3. 全域性併發：C4採用全域性併發的方式，允許垃圾收集器與應用程式執行緒併發工作，而不是在停頓期間獨佔堆記憶體。
  4. 分代收集：C4收集器通常使用分代收集策略，將堆記憶體劃分為不同的代。這使得它可以更有效地管理記憶體，降低了垃圾收集的頻率。
  5. 自適應調整：C4收集器具有自適應調整的能力，可以根據應用程式和硬體環境的變化自動調整其行為。

需要注意的是，C4垃圾收集器通常不是Oracle JDK的預設垃圾收集器，而是一種商業JVM的特性，如Azul Zing。C4垃圾收集器在一些商業JVM中提供，而不是在開源JVM中普遍使用。選擇使用C4垃圾收集器通常需要根據具體的商業JVM產品進行配置和許可。

ZGC

如果沒有足夠預算去使用商業解決方案，但能夠掌控軟硬體型號，使用較新的版本，同時又特別注重延遲，那ZGC很值得嘗試。

Z Garbage Collector（ZGC）是一種用於Java虛擬機器（JVM）的垃圾收集器，旨在降低大型Java應用程式的停頓時間。ZGC是由Oracle開發的，並於Java 11中首次引入。以下是ZGC垃圾收集器的一些關鍵特點和優勢：

  1. 低停頓時間：ZGC的主要設計目標之一是降低停頓時間。它採用了一種併發的方式來執行垃圾收集，以減少應用程式的停頓時間。通常，垃圾收集過程中的停頓時間在幾毫秒到幾十毫秒之間，這對需要快速響應的應用程式非常有利。
  2. 大堆支援：ZGC適用於非常大的堆記憶體，可以處理幾十GB甚至上百GB的堆記憶體。這使其適合大型資料處理應用和記憶體密集型應用。
  3. 併發處理：ZGC的標記、清理和整理階段是併發進行的，這意味著垃圾收集過程與應用程式執行緒並行執行。這有助於減少停頓時間。
  4. 可預測性：ZGC致力於提供可預測的停頓時間，這對於需要滿足服務級別協議（SLA）的應用程式非常重要。
  5. 無需特殊硬體：ZGC不需要特殊的硬體支援，可以在標準的x86架構上執行。
  6. 多平臺支援：ZGC支援多種平臺，包括Linux、Windows和macOS。

需要注意的是，ZGC並不適用於所有應用程式。它在大型記憶體需求和低停頓時間要求的情況下表現最佳。對於小型應用程式，傳統的垃圾收集器（如G1或CMS）可能足夠了。在選擇ZGC時，還需要考慮Java版本的相容性，因為它是從Java 11開始引入的。

總的來說，ZGC是一種在大型記憶體應用程式中降低停頓時間的有效垃圾收集器，特別適用於需要可預測性和低延遲的應用程式。

CMS/G1

如果接手的是遺留系統，軟硬體基礎設施和JDK版本都比較落後，那就根據記憶體規模衡量一 下，對於大概4GB到6GB以下的堆記憶體，CMS一般能處理得比較好，而對於更大的堆記憶體，可重點考察一下G1。

五、記憶體分配策略

image-20231029231733213

新生代和老年代的 GC 操作

  • 新生代 GC 操作：Minor GC
    • 發生的非常頻繁，速度較塊。
  • 老年代 GC 操作：Full GC / Major GC
    • 經常伴隨著至少一次的 Minor GC；
    • 速度一般比 Minor GC 慢上 10 倍以上。

5.1優先在 Eden 區分配

image-20231029233351944
  1. new的物件先放在伊甸園區，此區有大小限制
  2. 當伊甸園區滿時，程式又需要建立物件，此時JVM的垃圾回收器（YGC/Minor GC）對伊甸園區進行垃圾回收，將伊甸園區中不被物件所引用的物件進行銷燬，再載入新的物件放到此區中。
  3. 然後將伊甸園中剩餘的物件（存活的）移動到倖存者0區。
  4. 當再次垃圾回收時，還是先銷燬物件並將存活物件移動到倖存者1區，然後將處在倖存者0區的也移動到倖存者1區（這些對象的年齡++）。
  5. 接下來重複，每次放入倖存者區時，放入空的那個（to區）
  6. 當再次垃圾回收時， 且當倖存者區中的物件的年齡有到達15的（可以更改-XX:MaxTenuringThreshold=?），則將此物件移動到老年區。
  7. 老年區相對悠閒，當老年區記憶體不足時，觸發Major GC,進行老年區的清理。
  8. 若老年區執行了Major GC之後發現依然無法進行物件的儲存，就會產生OOM異常。
  • 虛擬機器引數：
    • -Xmx：Java 堆的最大值；
    • -Xms：Java 堆的最小值；
    • -Xmn：新生代大小；
    • -XX:SurvivorRatio=8：Eden 區 / Survivor 區 = 8 : 1

5.2大物件直接進入老年代

  • 大物件定義： 需要大量連續記憶體空間的 Java 物件。例如那種很長的字串或者陣列。
  • 設定物件直接進入老年代大小限制：
    • -XX:PretenureSizeThreshold：單位是位元組；
      • 只對 Serial 和ParNew兩款收集器有效。
    • 目的： 因為新生代採用的是複製演算法收集垃圾，大物件直接進入老年代可以避免在 Eden 區和 Survivor 區發生大量的記憶體複製。

5.3長期存活的物件將進入老年代

  • 固定物件年齡判定： 虛擬機器給每個物件定義一個年齡計數器，物件每在 Survivor 中熬過一次 Minor GC，年齡 +1，達到 -XX:MaxTenuringThreshold 設定值後，會被晉升到老年代，-XX:MaxTenuringThreshold 預設為 15；
  • 動態物件年齡判定： Survivor 中有相同年齡的物件的空間總和大於 Survivor 空間的一半，那麼，年齡大於或等於該年齡的物件直接晉升到老年代。

5.4空間分配擔保

我們知道，新生代採用的是複製演算法清理記憶體，每一次 Minor GC，虛擬機器會將 Eden 區和其中一塊 Survivor 區的存活物件複製到另一塊 Survivor 區，但 當出現大量物件在一次 Minor GC 後仍然存活的情況時，Survivor 區可能容納不下這麼多物件，此時，就需要老年代進行分配擔保，即將 Survivor 無法容納的物件直接進入老年代。

這麼做有一個前提，就是老年代得裝得下這麼多物件。可是在一次 GC 操作前，虛擬機器並不知道到底會有多少物件存活，所以空間分配擔保有這樣一個判斷流程：

  • 發生 Minor GC 前，虛擬機器先檢查老年代的最大可用連續空間是否大於新生代所有物件的總空間；
    • 如果大於，Minor GC 一定是安全的；
    • 如果小於，虛擬機器會檢視 HandlePromotionFailure 引數，看看是否允許擔保失敗；
      • 允許失敗：嘗試著進行一次 Minor GC；
      • 不允許失敗：進行一次 Full GC；
  • 不過 JDK 6 Update 24 後，HandlePromotionFailure 引數就沒有用了，規則變為只要老年代的連續空間大於新生代物件總大小或者歷次晉升的平均大小就會進行 Minor GC，否則將進行 Full GC。

5.5etaspace 元空間與 PermGen 永久代

Java 8 徹底將永久代 (PermGen) 移除出了 HotSpot JVM，將其原有的資料遷移至 Java Heap 或 Metaspace。

移除 PermGen 的原因：

  • PermGen 記憶體經常會溢位，引發惱人的 java.lang.OutOfMemoryError: PermGen，因此 JVM 的開發者希望這一塊記憶體可以更靈活地被管理，不要再經常出現這樣的OOM；
  • 移除 PermGen 可以促進HotSpot JVM與JRockit VM的融合，因為 JRockit 沒有永久代。

移除 PermGen 後，方法區和字串常量的位置：

  • 方法區：移至 Metaspace；
  • 字串常量：移至 Java Heap。

Metaspace 的位置： 本地堆記憶體(native heap)。

Metaspace 的優點： 永久代 OOM 問題將不復存在，因為預設的類的後設資料分配只受本地記憶體大小的限制，也就是說本地記憶體剩餘多少，理論上 Metaspace 就可以有多大；

JVM引數：

  • -XX:MetaspaceSize：分配給類後設資料空間（以位元組計）的初始大小，為估計值。MetaspaceSize的值設定的過大會延長垃圾回收時間。垃圾回收過後，引起下一次垃圾回收的類後設資料空間的大小可能會變大。
  • -XX:MaxMetaspaceSize：分配給類後設資料空間的最大值，超過此值就會觸發Full GC，取決於系統記憶體的大小。JVM會動態地改變此值。
  • -XX:MinMetaspaceFreeRatio：一次GC以後，為了避免增加後設資料空間的大小，空閒的類後設資料的容量的最小比例，不夠就會導致垃圾回收。
  • -XX:MaxMetaspaceFreeRatio：一次GC以後，為了避免增加後設資料空間的大小，空閒的類後設資料的容量的最大比例，不夠就會導致垃圾回收。

相關文章