作者 | 波哥

審校 | 重樓

Java虛擬機（JVM）的自動內存管理是Java開發者的福音，它通過垃圾收集（GC）機制自動回收不再使用的對象，極大地簡化了內存管理。然而，不恰當的GC配置或不理想的垃圾收集器選擇可能會對應用性能產生負面影響。為了優化Java應用的性能，深入理解GC的原理和策略是至關重要的。本文筆者將詳細探討JVM的垃圾收集機制，包括內存模型、GC算法、各種垃圾收集器的特點及其調優策略。

一、JVM內存模型深入解析

JVM的內存模型是理解GC機制的基礎。JVM將內存分為多個區域，主要包括堆（Heap）、方法區（Method Area）、程序計數器（Program Counter Register）、虛擬機棧（VM Stack）和本地方法棧（Native Method Stack）。

1.堆（Heap）

堆內存是Java虛擬機（JVM）管理的最大一塊內存區域，它被所有線程共享，主要用于存放對象實例和數組。從垃圾收集的角度，堆內存進一步細分為新生代（Young Generation）、老年代（Old Generation）以及元空間（Metaspace，在Java 8之后取代了永久代PermGen）。

（1）新生代（Young Generation）

新生代是大多數新創建的對象的誕生地。由于對象的生存周期大多數較短，新生代的垃圾收集（Minor GC）發生頻繁但速度快。新生代進一步分為三個區域：

• Eden區：幾乎所有新生成的對象首先都是在Eden區分配。
• 兩個Survivor區（S0和S1）：用于存放從Eden區和Survivor區經過一次Minor GC后仍然存活的對象。在每次Minor GC后，存活的對象會被移動到一個Survivor區，而另一個空閑的Survivor區將用于下一輪的存活對象移動。

（2）老年代（Old Generation）

隨著時間的推移，一些在新生代中經歷了多次GC依然存活的對象會被移動到老年代。老年代用于存放應用中生命周期長的對象。相較于新生代，老年代的空間更大，GC發生的頻率更低，但每次GC的時間更長。

對象進入老年代（Old Generation）通常是基于它們的存活周期。JVM采用分代垃圾收集策略，其中對象首先在新生代（Young Generation）分配。隨著垃圾收集的進行，只有存活下來的對象才會逐步晉升到老年代。具體而言，有幾種情況下對象會進入到老年代：

（3）經歷多次Minor GC后仍然存活的對象

新生代中的對象在經歷了一定數量的Minor GC（垃圾收集只針對新生代的收集稱為Minor GC）后，如果仍然存活，它們會被移動到老年代。JVM中有一個年齡計數器，每當對象在Minor GC后仍然存活，它的年齡就會增加。當對象的年齡增加到一定閾值（默認為15，但可以通過JVM參數-XX:MaxTenuringThreshold進行調整）時，這個對象就會被晉升到老年代。

（4）大對象直接分配到老年代

所謂的大對象是指需要大量連續內存空間的Java對象，例如那些很大的數組和長字符串。如果新生代中的Eden區無法容納一個新創建的對象，JVM就會直接將這個對象分配到老年代。這樣做是為了避免在新生代中為大對象分配內存后，進行Minor GC時發生大量的內存復制操作（因為新生代使用的是復制算法）。通過JVM參數-XX:PretenureSizeThreshold可以設置大對象的大小閾值。

（5）動態年齡判斷

在新生代的兩個Survivor區之間，對象每經過一次Minor GC就會年齡增加。如果在Survivor空間中相同年齡所有對象的大小的總和大于Survivor空間的一半，年齡大于或等于該年齡的對象就可以直接進入老年代，無需等到-XX:MaxTenuringThreshold設置的年齡。

（6）空間分配擔保

在進行Minor GC前，虛擬機會檢查老年代最大可用的連續空間是否大于新生代所有對象的總空間。如果這個條件不能滿足，虛擬機會提前將新生代中的部分對象轉移到老年代中，這個過程稱為“空間分配擔保”。目的是確保Minor GC可以順利完成，不會因為老年代空間不足而觸發更耗時的Full GC。

（7）元空間（Metaspace）

元空間用于存放類的元數據信息，如類的定義信息、常量、靜態變量等，并使用本地內存（而非JVM堆內存）。在Java 8之前，這部分數據被存放在永久代中。元空間的引入是為了避免永久代容易發生的內存溢出問題，并提供更靈活的內存管理。

2.方法區（Method Area）

方法區（Method Area）是堆的一部分，也被稱為非堆（Non-Heap），它被所有線程共享。方法區主要用于存放已被虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯后的代碼等數據。
在Java 8及之后的版本中，傳統的永久代（PermGen）被元空間（Metaspace）所取代。與永久代不同，元空間并不在虛擬機內存中，而是使用本地內存，因此，元空間的大小只受本地內存限制。

方法區的特點

• 靜態存儲：方法區存儲的信息相對靜態，包括類的結構（如運行時常量池、字段和方法數據）以及方法和構造函數的代碼。
• 全局共享：方法區被所有線程共享，這意味著它不像堆那樣頻繁地進行垃圾收集。實際上，方法區的垃圾收集主要針對常量池的回收和對類型的卸載。
• 動態擴展：雖然方法區的初始大小有限，但它可以在運行時動態擴展，也可以設置最大空間大小，以防止其過度消耗內存。

方法區的垃圾收集

方法區的垃圾收集比較少見且難以執行，主要涉及兩部分工作：廢棄常量的回收和無用類的卸載。無用類的卸載條件相對嚴格，需要同時滿足以下三個條件：

• 該類所有的實例都已經被回收，也就是說Java堆中不存在該類的任何實例。
• 加載該類的ClassLoader已經被回收。
• 該類對應的java.lang.Class對象沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。

二、GC算法的探究

GC算法是實現垃圾收集的具體方法。主要的GC算法包括標記-清除（Mark-Sweep）、復制（Copying）和標記-整理（Mark-Compact），下面筆者將詳細介紹這三種算法的工作原理以及它們的優缺點。

1.標記-清除算法

（1）工作原理

• 標記階段：從一組根對象（通常是活躍線程的局部變量和輸入參數、靜態字段等）開始遍歷，標記所有從這些根對象可達的對象。
• 清除階段：掃描整個堆空間，回收所有未被標記的對象所占用的內存。

（2）優點

• 簡單直接，實現相對容易。
• 不需要額外移動對象，減少了額外的開銷。

（3）缺點

• 執行過程中會產生內存碎片，導致后續可能無法為大對象分配連續內存空間。
• 需要暫停應用程序執行（Stop-The-World），可能會導致應用響應時間變長。

2.復制算法

（1）工作原理

• 將可用內存劃分為大小相等的兩塊，每次只使用其中一塊。
• 當這一塊的內存快用完時，將存活的對象復制到另一塊空閑區域。
• 清空已使用的內存塊，交換兩個內存區域的角色。

（2）優點

• 解決了標記-清除算法中的內存碎片問題。
  適合存活對象較少的場景，如新生代的垃圾收集。

（3）缺點

• 需要將存活的對象復制到另一塊內存區域，增加了復制成本，特別是當存活對象較多時。
  內存使用效率低，因為任何時候只有一半的內存區域被使用。

3.標記-整理算法

（1）工作原理

• 標記階段：與標記-清除算法相同，從根集合出發標記所有可達的對象。
• 整理階段：將所有存活的對象壓縮到堆的一端，然后清理掉邊界以外的內存。

（2）優點

• 解決了內存碎片問題，為大對象的分配提供了連續的內存空間。
• 避免了復制算法中的高成本復制操作，更適合老年代的垃圾收集。

（3）缺點

• 需要移動對象，并更新對象引用的位置，增加了額外的開銷。
• 同樣需要暫停應用程序執行，可能會影響應用的響應時間。

現代JVM實現通常采用以上基本GC算法的變體或組合，以達到更高的垃圾收集效率和更低的停頓時間。例如：G1收集器就是將堆劃分為多個區域（Region），并根據每個區域的垃圾回收價值進行增量收集，旨在平衡吞吐量和停頓時間。ZGC和Shenandoah收集器則采用了基于Region的復制算法，實現了幾乎全程并發的垃圾收集，極大地減少了停頓時間。

JVM提供了多種垃圾收集器，下面我們大概介紹下目前主流的幾種垃圾回收器及每種收集器的適用場景。

• Serial收集器Serial收集器是最簡單的GC實現，它使用單線程進行垃圾收集。在進行GC時，需要暫停其他所有工作線程（"Stop The World"），因此不適合多處理器環境或要求低延遲的應用。
• Parallel（并行）收集器Parallel收集器類似于Serial收集器，但它使用多線程進行垃圾收集，可以顯著減少GC的停頓時間。它主要關注達到一個可接受的吞吐量（應用時間與GC時間的比率）。
• Concurrent Mark Sweep（CMS）收集器CMS收集器的目標是盡可能減少應用停頓時間。它通過并發標記和并發清除實現了這一點，但是CMS收集器可能會產生較多的內存碎片。
• G1收集器G1收集器是一種服務器端的垃圾收集器，旨在替代CMS收集器，它通過將堆劃分為多個區域（Region）并并行處理這些區域來減少停頓時間，同時提供了更細粒度的GC控制。
• ZGC和Shenandoah收集器ZGC和Shenandoah是實驗性的低延遲垃圾收集器，旨在實現幾乎不停頓的垃圾收集。它們通過使用讀寫屏障和并發線程來實現這一目標，適用于需要極低停頓時間的應用。

三、垃圾收集器的調優實踐

以上我們詳細介紹了垃圾回收算法和主流的垃圾回收器，接下來我們詳細介紹下在實際應用中，該如何根據具體應用特性進行調優。以下是一些調優的通用策略：

• 選擇合適的垃圾收集器根據應用的需求（如響應時間要求、吞吐量要求等）和資源限制（如CPU、內存大小等），選擇最適合的垃圾收集器。
• 堆大小調整適當地調整堆大小可以平衡GC的頻率和停頓時間。一般而言，增大堆大小會減少GC的頻率，但可能增加GC的停頓時間。
• 監控和分析GC日志通過開啟GC日志，可以獲得垃圾收集的詳細信息，如各階段的耗時、回收量等。分析這些數據可以幫助識別性能瓶頸和調優方向。
• 細化GC參數設置

JVM提供了豐富的GC相關參數，通過調整這些參數（如新生代與老年代的比例、觸發Full GC的閾值等），可以微調垃圾收集的行為，優化性能。

深入理解JVM的垃圾收集機制和各種垃圾收集器的特點是進行有效性能調優的前提。通過選擇合適的垃圾收集器并適當調優，可以顯著提升Java應用的性能，滿足不同場景下對響應時間和吞吐量的需求。記住，沒有一勞永逸的解決方案，性能優化是一個持續的過程，需要不斷地監控、評估和調整。

作者介紹

波哥，互聯行業從業10余年，先后擔任項目總監及架構師。目前專攻技術，喜歡研究技術原理。技術全面，主攻Java，精通JVM底層機制及Spring全家桶底層框架原理，熟練掌握當前主流的中間件、服務網格等技術原理。