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

一、運行時數據區

Java虛擬機在執行Java程序的過程中會把它所管理的內存劃分為若干個不同的數據區域。這些區域 有各自的用途，以及創建和銷毀的時間，有的區域隨著虛擬機進程的啟動而一直存在，有些區域則是 依賴用戶線程的啟動和結束而建立和銷毀。根據《Java虛擬機規范》的規定，Java虛擬機所管理的內存將會包括以下幾個運行時數據區域

1.1程序計數器

線程私有

是一個非常小的內存區域，用于存儲當前線程正在執行的字節碼指令的地址。每個線程在JVM中都有一個獨立的程序計數器。當JVM執行一條字節碼指令時，程序計數器會更新為下一條指令的地址。

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

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

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

1.2虛擬機棧

線程私有

每個方法被執行的時候，Java虛擬機都 會同步創建一個棧幀用于存儲局部變量表、操作數棧、動態連接、方法出口等信息。

• 服務于 Java 方法；
• 可能拋出的異常：
  • OutOfMemoryError（在虛擬機棧可以動態擴展的情況下，擴展時無法申請到足夠的內存）；
  • *Error（線程請求的棧深度 > 虛擬機所允許的深度）；
• 虛擬機參數設置：-Xss.

局部變量表存放了編譯期可知的各種Java虛擬機基本數據類型（boolean、byte、char、short、int、 float、long、double）、對象引用。

1.3本地方法棧

線程私有

• 服務于 native 方法；
• 可能拋出的異常：與 Java 虛擬機棧一樣。

1.4堆

線程共享

“幾乎”所有的對象實例都在這里分配內存

由于即時編 譯技術的進步，尤其是逃逸分析技術的日漸強大，棧上分配、標量替換優化手段已經導致一些微妙 的變化悄然發生，所以說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程序使用直接內存，用于數據緩沖區

由于直接內存在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. 如何保證創建內存時，劃分內存線程安全

劃分可用的內存

• 指針碰撞（內存分配規整）
  • 用過的內存放一邊，沒用過的內存放一邊，中間用一個指針分隔；
  • 分配內存的過程就是將指針向沒用過的內存那邊移動所需的長度；

• 空閑列表（內存分配不規整）
  • 維護一個列表，記錄哪些內存塊是可用的；
  • 分配內存時，從列表上選取一塊足夠大的空間分給對象，并更新列表上的記錄；

劃分內存的指針的同步問題

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

2.2對象的內存布局

對象在堆內存中的存儲布局可以劃分為三個部分：
對象頭(Header)、實例數據(Instance Data)和對齊填充(Padding)。

• 對象頭：
  • 第一部分(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本身。

直接指針訪問

直接指針訪問方式在 Java 堆對象的實例數據中存放了一個指向對象類型數據的指針，在 HotSpot 中，這個指針會被存放在對象頭中。

優勢：減少了一次指針定位對象實例數據的開銷，速度更快。

三、OOM 異常

3.1Java 堆溢出

• 出現標志：java.lang.OutOfMemoryError: Java heap space
• 解決方法：
  • 先通過內存映像分析工具分析 Dump 出來的堆轉儲快照，確認內存中的對象是否是必要的，即分清楚是出現了內存泄漏還是內存溢出；
  • 如果是內存泄漏，通過工具查看泄漏對象到 GC Root 的引用鏈，定位出泄漏的位置；
  • 如果不存在泄漏，檢查虛擬機堆參數（-Xmx 和 -Xms）是否可以調大，檢查代碼中是否有哪些對象的生命周期過長，嘗試減少程序運行期的內存消耗。
• 虛擬機參數：
  • -XX:HeapDumpOnOutOfMemoryError：讓虛擬機在出現內存泄漏異常時 Dump 出當前的內存堆轉儲快照用于事后分析。

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

• 單線程下，棧幀過大、虛擬機容量過小都不會導致 OutOfMemoryError，只會導致 *Error（棧會比內存先爆掉），一般多線程才會出現 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判斷對象的生死

什么時候回收對象？當然是這個對象再也不會被用到的時候回收。

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

4.1.1判斷對象是否可用的算法

引用計數算法

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

可達性分析算法（主流）

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

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

并發情況的可達性分析

在可達性分析中，第一階段 ”根節點枚舉“ 是必須 STW 的，那么為什么因此必須在一個能保障一致性的快照上才能進行對象圖的遍歷，而不是同步用戶線程進行呢？

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

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

關于可達性分析的掃描過程，可以看作對象圖上一股以灰色為波峰的波紋從黑向白推進的過程，此時如果用戶線程改變了對象的引用關系，會發生兩種情況：

• 一種是把原本消亡的對象錯誤標記為存活， 這下次收集清理掉就好。
• 另一種是把原本存活的對象錯誤標記為已消亡，那么可能會導致程序崩潰。

如上圖所示，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垃圾收集算法

4.2.1標記 - 清除算法

• 算法描述：

  • 先標記出所有需要回收的對象（圖中深色區域）；
  • 標記完后，統一回收所有被標記對象（留下狗啃似的可用內存區域……）。

• 不足：

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

4.2.2標記 - 復制算法

• 算法描述：

  • 將可用內存分為大小相等的兩塊，每次只使用其中一塊；
  • 當一塊內存用完時，將這塊內存上還存活的對象復制到另一塊內存上去，將這一塊內存全部清理掉。

• 不足： 可用內存縮小為原來的一半，適合GC過后只有少量對象存活的新生代。

• 節省內存的方法：

  • 新生代中的對象 98% 都是朝生夕死的，所以不需要按照 1:1 的比例對內存進行劃分；
  • 把內存劃分為：
    • 1 塊比較大的 Eden 區；
    • 2 塊較小的 Survivor 區；
  • 每次使用 Eden 區和 1 塊 Survivor 區；
  • 回收時，將以上 2 部分區域中的存活對象復制到另一塊 Survivor 區中，然后將以上兩部分區域清空；
  • JVM 參數設置：-XX:SurvivorRatio=8 表示 Eden 區大小 / 1 塊 Survivor 區大小 = 8。

4.2.3標記 - 整理算法

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

進化：分代收集算法

• 新生代： GC 過后只有少量對象存活 —— 復制算法
• 老年代： GC 過后對象存活率高 —— 標記 - 整理算法

4.3HotSpot 中 GC 算法的實現

通過之前的分析，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的卡頁內存塊

一個卡頁的內存中通常包含不止一個對象，只要卡頁內有一個（或更多）對象的字段存在著跨代 指針，那就將對應卡表的數組元素的值標識為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

Serial / ParNew 搭配 Serial Old 收集器

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 收集器

回收老年代

參數設置：

• -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)收集器

在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是一個集合，里面存儲的元素是卡表的索引號。這種“雙向”的卡表結構（卡表是“我指向誰”，這種結構還記錄了“誰指向我”）比原來的卡表實現起來更復雜

2. 在并發標記階段如何保證收集線程與用戶線程互不干擾地運行

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 日志解讀

低延遲收集器

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。

五、內存分配策略

新生代和老年代的 GC 操作

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

5.1優先在 Eden 區分配

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以后，為了避免增加元數據空間的大小，空閑的類元數據的容量的最大比例，不夠就會導致垃圾回收。

總結

以上是生活随笔為你收集整理的JVM学习-自动内存管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。