讀全文時間大約需要15分鐘。
最近處理ES的問題，ES默認GC方式是CMS。學習完JVM的G1GC后最終決定將ES集群GC方式調整為G1GC。
垃圾優先型垃圾回收器 (G1 GC) 是適用于 Java HotSpot VM 的低暫停、服務器風格的分代式垃圾回收器。G1 GC 使用并發和并行階段實現其目標暫停時間，并保持良好的吞吐量。當 G1 GC 確定有必要進行垃圾回收時，它會先收集存活數據最少的區域（垃圾優先）。
G1提供了兩種GC模式，Young GC和Mixed GC，兩種都是完全Stop The World的。 * Young GC：選定所有年輕代里的Region。通過控制年輕代的region個數，即年輕代內存大小，來控制young GC的時間開銷。 * Mixed GC：選定所有年輕代里的Region，外加根據global concurrent marking統計得出收集收益高的若干老年代Region。在用戶指定的開銷目標范圍內盡可能選擇收益高的老年代Region。
垃圾回收器 (GC) 是一個內存管理工具。G1 GC 通過以下操作實現自動內存管理：
將對象分配給年輕代，并將老化對象晉升到老年代。
通過并發（并行）標記階段，查找老年代中的存活對象。當總的 Java 堆占用率超過默認的閾值時，Java HotSpot VM 將觸發標記階段。
通過并行復制壓縮存活對象，恢復空閑內存。
現在，我們來看看如何針對評估、分析和性能來調整和調優 G1 GC。我們假定您對 Java 垃圾回收有基本的了解。
G1 GC 是區域化、分代式垃圾回收器，這意味著 Java 對象堆（堆）被劃分成大小相同的若干區域。啟動時，Java 虛擬機 (JVM) 會設置區域大小。區域大小從 1 MB 到 32 MB 不等，具體取決于堆大小。目標是產生不超過 2048 個區域。Eden、存活空間和老年代是一系列不連續的邏輯區域。
G1 GC 有一個力求達到的暫停時間目標（軟實時）。在年輕代回收期間，G1 GC 會調整其年輕代空間（eden 和存活空間大小）以滿足軟實時目標。在混合回收期間，G1 GC 會根據混合垃圾回收的目標次數調整所回收的舊區域數量，并調整堆的每個區域中存活對象的百分比，以及總體可接受的堆廢物百分比。
G1 GC 將一組或多組區域（稱為回收集 (CSet)）中的存活對象以增量、并行的方式復制到不同的新區域來實現壓縮，從而減少堆碎片。目標是從可回收空間最多的區域開始，盡可能回收更多的堆空間，同時盡可能不超出暫停時間目標（垃圾優先）。
G1 GC 使用獨立的記憶集 (RSet) 跟蹤對區域的引用。獨立的 RSet 可以并行、獨立地回收區域，因為只需要對區域（而不是整個堆）的 RSet 進行區域引用掃描。G1 GC 使用后寫屏障記錄堆的更改和更新 RSet。
垃圾回收階段
除了構成停頓 (STW) 年輕代和混合垃圾回收的疏散暫停（如下所述），G1 GC 還具有并行、并發和多階段標記周期。G1 GC 使用初始快照 (SATB) 算法，在標記周期之初為堆中的存活對象集創建快照。存活對象集包括快照中的存活對象，以及標記周期開始以來所分配的對象。G1 GC 標記算法使用預寫屏障記錄和標記作為邏輯快照一部分的對象。
年輕代垃圾回收
G1 GC 可滿足來自被添加到 eden 區域集的區域的大多數分配請求。在年輕代垃圾回收期間，G1 GC 會同時回收 eden 區域和上次垃圾回收的存活區域。Eden 和存活區的存活對象將被復制或疏散到新的區域集。特定對象的目標區域取決于對象的年齡；足夠老的對象疏散到老年代區域（也就晉級）；否則疏散到存活區，并將包含在下一次年輕代或混合垃圾回收的 CSet 中。
混合垃圾回收
成功完成并發標記周期后，G1 GC 從執行年輕代垃圾回收切換為執行混合垃圾回收。在混合垃圾回收期間，G1 GC 可以將一些舊的區域添加到 eden 和存活區供將來回收。所添加舊區域的確切數量由一系列標志控制。關于標志的信息，將在后面討論（請參見"掌握混合垃圾回收"）。G1 GC 回收了足夠的舊區域后（經過多次混合垃圾回收），G1 將恢復執行年輕代垃圾回收，直到下一個標記周期完成。
標記周期的各個階段
標記周期包括以下幾個階段：
初始標記階段：在此階段，G1 GC 對根進行標記。該階段與常規的 (STW) 年輕代垃圾回收密切相關。
根區域掃描階段：G1 GC 在初始標記的存活區掃描對老年代的引用，并標記被引用的對象。該階段與應用程序（非 STW）同時運行，并且只有完成該階段后，才能開始下一次 STW 年輕代垃圾回收。
并發標記階段：G1 GC 在整個堆中查找可訪問的（存活的）對象。該階段與應用程序同時運行，可以被 STW 年輕代垃圾回收中斷。
重新標記階段：該階段是 STW 回收，幫助完成標記周期。G1 GC 清空 SATB 緩沖區，跟蹤未被訪問的存活對象，并執行引用處理。
清理階段：在這個最后階段，G1 GC 執行統計和 RSet 凈化的 STW 操作。在統計期間，G1 GC 會識別完全空閑的區域和可供進行混合垃圾回收的區域。清理階段在將空白區域重置并返回到空閑列表時為部分并發。
重要的默認值
G1 GC 是自適應的垃圾回收器，提供了若干默認設置，使其無需修改即可高效地工作。以下是重要選項及其默認值的列表。此列表適用于最新的 Java HotSpot VM build 24。您可以通過在 JVM 命令行輸入下列選項和已更改的設置，根據您的應用程序性能需求調整和調優 G1 GC。
-XX:G1HeapRegionSize=n設置的 G1 區域的大小。值是 2 的冪，范圍是 1 MB 到 32 MB 之間。目標是根據最小的 Java 堆大小劃分出約 2048 個區域。
-XX:MaxGCPauseMillis=200為所需的最長暫停時間設置目標值。默認值是 200 毫秒。指定的值不適用于您的堆大小。
-XX:G1NewSizePercent=5設置要用作年輕代大小最小值的堆百分比。默認值是 Java 堆的 5%。這是一個實驗性的標志。有關示例，請參見"如何解鎖實驗性虛擬機標志"。此設置取代了 -XX:DefaultMinNewGenPercent 設置。Java HotSpot VM build 23 中沒有此設置。
-XX:G1MaxNewSizePercent=60設置要用作年輕代大小最大值的堆大小百分比。默認值是 Java 堆的 60%。這是一個實驗性的標志。有關示例，請參見"如何解鎖實驗性虛擬機標志"。此設置取代了 -XX:DefaultMaxNewGenPercent 設置。Java HotSpot VM build 23 中沒有此設置。
-XX:ParallelGCThreads=n設置 STW 工作線程數的值。將 n 的值設置為邏輯處理器的數量。n 的值與邏輯處理器的數量相同，最多為 8。
如果邏輯處理器不止八個，則將 n 的值設置為邏輯處理器數的 5/8 左右。這適用于大多數情況，除非是較大的 SPARC 系統，其中 n 的值可以是邏輯處理器數的 5/16 左右。
-XX:ConcGCThreads=n設置并行標記的線程數。將 n 設置為并行垃圾回收線程數 (ParallelGCThreads) 的 1/4 左右。
-XX:InitiatingHeapOccupancyPercent=45設置觸發標記周期的 Java 堆占用率閾值。默認占用率是整個 Java 堆的 45%。
-XX:G1MixedGCLiveThresholdPercent=65為混合垃圾回收周期中要包括的舊區域設置占用率閾值。默認占用率為 65%。這是一個實驗性的標志。有關示例，請參見"如何解鎖實驗性虛擬機標志"。此設置取代了 -XX:G1OldCSetRegionLiveThresholdPercent 設置。Java HotSpot VM build 23 中沒有此設置。
-XX:G1HeapWastePercent=10設置您愿意浪費的堆百分比。如果可回收百分比小于堆廢物百分比，Java HotSpot VM 不會啟動混合垃圾回收周期。默認值是 10%。Java HotSpot VM build 23 中沒有此設置。
-XX:G1MixedGCCountTarget=8設置標記周期完成后，對存活數據上限為 G1MixedGCLIveThresholdPercent 的舊區域執行混合垃圾回收的目標次數。默認值是 8 次混合垃圾回收。混合回收的目標是要控制在此目標次數以內。Java HotSpot VM build 23 中沒有此設置。
-XX:G1OldCSetRegionThresholdPercent=10設置混合垃圾回收期間要回收的最大舊區域數。默認值是 Java 堆的 10%。Java HotSpot VM build 23 中沒有此設置。
-XX:G1ReservePercent=10設置作為空閑空間的預留內存百分比，以降低目標空間溢出的風險。默認值是 10%。增加或減少百分比時，請確保對總的 Java 堆調整相同的量。Java HotSpot VM build 23 中沒有此設置。
如何解鎖實驗性虛擬機標志
要更改實驗性標志的值，必須先對其解鎖。解鎖方法是：在命令行中的實驗性標志前，顯式地設置 -XX:+UnlockExperimentalVMOptions。例如：
> java -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=10 -XX:G1MaxNewSizePercent=75 G1test.jar評估和微調 G1 GC 時，請記住以下建議：
· 年輕代大小：避免使用 -Xmn 選項或 -XX:NewRatio 等其他相關選項顯式設置年輕代大小。固定年輕代的大小會覆蓋暫停時間目標。
· 暫停時間目標：每當對垃圾回收進行評估或調優時，都會涉及到延遲與吞吐量的權衡。G1 GC 是增量垃圾回收器，暫停統一，同時應用程序線程的開銷也更多。G1 GC 的吞吐量目標是 90% 的應用程序時間和 10%的垃圾回收時間。如果將其與 Java HotSpot VM 的吞吐量回收器相比較，目標則是 99% 的應用程序時間和 1% 的垃圾回收時間。因此，當您評估 G1 GC 的吞吐量時，暫停時間目標不要太嚴苛。目標太過嚴苛表示您愿意承受更多的垃圾回收開銷，而這會直接影響到吞吐量。當您評估 G1 GC 的延遲時，請設置所需的（軟）實時目標，G1 GC 會盡量滿足。副作用是，吞吐量可能會受到影響。
· 掌握混合垃圾回收：當您調優混合垃圾回收時，請嘗試以下選項。有關這些選項的信息，請參見"重要的默認值"：
-XX:InitiatingHeapOccupancyPercent· 用于更改標記閾值。
-XX:G1MixedGCLiveThresholdPercent 和 -XX:G1HeapWastePercent· 當您想要更改混合垃圾回收決定時。
-XX:G1MixedGCCountTarget 和 -XX:G1OldCSetRegionThresholdPercent· 當您想要調整舊區域的 CSet 時。
有關溢出和用盡的日志消息
當您在日志中看到目標空間溢出/用盡的消息時，意味著 G1 GC 沒有足夠的內存，供存活者和/或晉升對象使用。Java 堆不能擴展，因為已達到最大值。示例消息：
924.897: [GC pause (G1 Evacuation Pause) (mixed) (to-space exhausted), 0.1957310 secs]924.897:[GC pause (G1 Evacuation Pause) (mixed) (to-space overflow), 0.1957310 secs]要緩解此問題，請嘗試以下調整：
增加 -XX:G1ReservePercent 選項的值（并相應增加總的堆大小），為"目標空間"增加預留內存量。
通過減少 -XX:InitiatingHeapOccupancyPercent 提前啟動標記周期。
您也可以通過增加 -XX:ConcGCThreads 選項的值來增加并行標記線程的數目。
有關這些選項的描述，請參見"重要的默認值"。
參考資料：http://dwz.win/9Ze
JVM 調優是一個很大的話題，在回答“如何進行 JVM 調優？”之前，首先我們要回答一個更為關鍵的問題，那就是，我們為什么要進行 JVM 調優？
只有知道了為什么要進行 JVM 調優之后，你才能準確的回答出來如何進行 JVM 調優？
要進行 JVM 調優無非就是以下兩種情況：
所以，針對不同的 JVM 調優的手段和側重點也是不同的。
總的來說，JVM 進行調優的流程如下：
具體來說它們的執行如下。
先確定是目標驅動型的 JVM 調優，還是問題驅動型的 JVM 調優。
如果是目標性的 JVM 調優，那么 JVM 調優實現思路就比較簡單了，如：
如果是以問題驅動的 JVM 調優，那就要先分析問題是什么，然后再進行下一步的調優了。
我們可以借助于目前主流的監控工具 Prometheus + Grafana 和 JDK 自帶的命令行工具，如 jps、jstat、jinfo、jstack 等進行 JVM 運行情況的分析。
主要分析的點是 Young GC 和 Full GC 的頻率，以及垃圾回收的執行時間。
常見的 JVM 調優參數有以下幾個：
JVM 參數調整之后，我們要通過壓力測試來觀察 JVM 參數調整前和調整后的差別，以確認調整后的效果。
在確認了 JVM 參數調整后的效果滿足需求之后，就可以將 JVM 的參數配置應用與生產環境了。
除了以上常見的 JVM 調優參數之外，還有沒有其他重要的參數設置呢？
本文已收錄到我的面試小站 [www.javacn.site](https://www.javacn.site)，其中包含的內容有：Redis、JVM、并發、并發、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、設計模式、消息隊列等模塊。