• G1 GC是啟發式算法，會動態調整年輕代的空間大小。
• 目標也就是為了達到接近預期的暫停時間。
• G1提供了兩種GC模式，YoungGC和Mixed GC，兩種都是Stop The World(STW)的。

Young GC

YoungGC主要是對Eden區進行GC，它在Eden空間耗盡時會被觸發。
在這種情況下，Eden空間的數據移動到Survivor空間中，如果Survivor空間不夠，Eden空間的部分數據會直接晉升到老年代空間。Survivor區的數據移動到新的Survivor區中，也有部分數據晉升到老年代空間中。最終Eden空間的數據為空，GC停止工作，應用線程繼續執行。

Mixed GC

Mix GC不僅進行正常的新生代垃圾收集，同時也回收部分后臺掃描線程標記的老年代分區。
GC步驟分2步：全局并發標記（global concurrent marking）和 拷貝存活對象（evacuation）。
在進行Mix GC之前，會先進行global concurrent marking（全局并發標記）。global concurrent marking的執行過程是怎樣的呢？在G1GC中，它主要是為Mixed GC提供標記服務的，并不是一次GC過程的一個必須環節。

-XX:MaxGCPauseMillis

暫停時間，默認值200ms。這是一個軟性目標，G1會盡量達成，如果達不成，會逐漸做自我調整。

對于YoungGC來說，會逐漸減少Eden區個數，減少Eden空間那么Young GC的處理時間就會相應減少。對于MixedGC，G1會調整每次Choose Cset的比例，默認最大值是10%，當然每次選擇的Cset少了，所要經歷的MixedGC的次數會相應增加。

減少Eden的總空間時，就會更加頻繁的觸發Young GC，也就是會加快Mixed GC的執行頻率，因為MixedGC是由Young GC觸發的，或者說借機同時執行的。頻繁GC會對對應用的吞吐量造成影響，每次MixedGC回收時間太短，回收的垃圾量太少，可能最后GC的垃圾清理速度趕不上應用產生的速度，那么可能會造成串行的FullGC，這是要極力避免的。所以暫停時間肯定不是設置的越小越好，當然也不能設置的偏大，轉而指望G1自己會盡快的處理，這樣可能會導致一次全部并發標記后觸發的MixedGC次數變少，但每次的時間變長，STW時間變長，對應用的影響更加明顯。

-XX:G1HeapRegionSize

Region大小，若未指定則默認最多生成2048塊，每塊的大小需要為2的冪次方，如1,2,4,8,16,32，最大值為32M。
Region的大小主要是關系到Humongous Object的判定，當一個對象超過Region大小的一半時，則為巨型對象，那么其會至少獨占一個Region，如果一個放不下，會占用連續的多個Region。當一個Humongous Region放入了一個巨型對象，可能還有不少剩余空間，但是不能用于存放其他對象，這些空間就浪費了。所以如果應用里有很多大小差不多的巨型對象，可以適當調整Region的大小，盡量讓他們以普通對象的形式分配，合理利用Region空間。

-XX:G1NewSizePercent和-XX:G1MaxNewSizePercent

新生代比例有兩個數值指定，下限：-XX:G1NewSizePercent，默認值5%，上限：-XX:G1MaxNewSizePercent，默認值60%。
G1會根據實際的GC情況(主要是暫停時間)來動態的調整新生代的大小，主要是Eden Region的個數。最好是Eden的空間大一點，畢竟Young GC的頻率更大，大的Eden空間能夠降低Young GC的發生次數。但是Mixed GC是伴隨著Young GC一起的，如果暫停時間短，那么需要更加頻繁的Young GC，同時也需要平衡好Mixed GC中新生代和老年代的Region，因為新生代的所有Region都會被回收，如果Eden很大，那么留給老年代回收空間就不多了，最后可能會導致Full GC。

-XX:ConcGCThreads

通過 -XX:ConcGCThreads來指定并發GC線程數，默認是-XX:ParallelGCThreads/4，也就是在非STW期間的GC工作線程數，當然其他的線程很多工作在應用上。
當并發周期時間過長時，可以嘗試調大GC工作線程數，但是這也意味著此期間應用所占的線程數減少，會對吞吐量有一定影響。
ConcGCThreads = (3 + ParallelGCThreads) / 4

-XX:ParallelGCThreads

通過-XX:ParallelGCThreads來指定并行GC線程數，也就是在STW階段工作的GC線程數。
其值遵循以下原則：

如果用戶顯示指定了ParallelGCThreads，則使用用戶指定的值。否則需要根據實際的CPU所能夠支持的線程數來計算ParallelGCThreads的值。

如果物理CPU所能夠支持線程數小于8，則ParallelGCThreads的值為CPU所支持的線程數。這里的閥值為8，是因為JVM中調用nof_parallel_worker_threads接口所傳入的switch_pt的值均為8。

如果物理CPU所能夠支持線程數大于8，則ParallelGCThreads的值為8加上一個調整值，調整值的計算方式為：物理CPU所支持的線程數減去8所得值的5/8或者5/16，JVM會根據實際的情況來選擇具體是乘以5/8還是5/16。

ParallelGCThreads=8 + (N - 8) * 5 / 8
比如，在64線程的x86 CPU上，如果用戶未指定ParallelGCThreads的值，則默認的計算方式為：
ParallelGCThreads = 8 + (64 - 8) * (5/8) = 8 + 35 = 43。

-XX:G1MixedGCLiveThresholdPercent

通過這個參數指定被納入Cset的Region的存活空間占比閾值，不同版本默認值不同，有65%和85%。
在全局并發標記階段，如果一個Region的存活對象的空間占比低于此值，則會被納入Cset。此值直接影響到Mixed GC選擇回收的區域，當發現GC時間較長時，可以嘗試調低此閾值，盡量優先選擇回收垃圾占比高的Region，但此舉也可能導致垃圾回收的不夠徹底，最終觸發Full GC。

-XX:InitiatingHeapOccupancyPercent

通過這個參數指定觸發全局并發標記的老年代使用占比，默認值45%，也就是老年代占堆的比例超過45%。
如果Mixed GC周期結束后老年代使用率還是超過45%,那么會再次觸發全局并發標記過程，這樣就會導致頻繁的老年代GC，影響應用吞吐量。同時老年代空間不大，Mixed GC回收的空間肯定是偏少的。可以適當調高IHOP的值，當然如果此值太高，很容易導致年輕代晉升失敗而觸發Full GC，所以需要多次調整測試。

-XX:G1HeapWastePercent

通過這個參數指定觸發Mixed GC的堆垃圾占比，默認值5%，也就是在全局標記結束后能夠統計出所有Cset內可被回收的垃圾占整對的比例值，
如果超過5%，那么就會觸發之后的多輪Mixed GC，
如果不超過，那么會在之后的某次Young GC中重新執行全局并發標記。
可以嘗試適當的調高此閾值，能夠適當的降低Mixed GC的頻率。

-XX:G1OldCSetRegionThresholdPercent

通過這個參數指定每輪Mixed GC回收的Region最大比例，默認10%，也就是每輪Mixed GC附加的Cset的Region不超過全部Region的10%，最多10%，如果暫停時間短，那么可能會少于10%。
一般這個值不需要額外調整。

-XX:G1MixedGCCountTarget

通過這個參數指定一個周期內觸發Mixed GC最大次數，默認值8。
一次全局并發標記后，最多接著8次Mixed GC，把全局并發標記階段生成的Cset里的Region拆分為最多8部分，然后在每輪Mixed GC里收集一部分。
這個值要和上一個參數配合使用，8*10%=80%，應該來說會大于每次標記階段的Cset集合了。
一般此參數也不需額外調整。

-XX:G1ReservePercent

通過這個參數指定G1為分配擔保預留的空間比例，默認10%。也就是老年代會預留10%的空間來給新生代的對象晉升，如果經常發生新生代晉升失敗而導致Full GC，那么可以適當調高此閾值。但是調高此值同時也意味著降低了老年代的實際可用空間。

-XX:MaxTenuringThreshold

晉升年齡閾值，默認值15。
一般新生對象經過15次Young GC會晉升到老年代，巨型對象會直接分配在老年代，同時在Young GC時，如果相同age的對象占Survivors空間的比例超過 -XX:TargetSurvivorRatio的值(默認50%)，則會自動將此次晉升年齡閾值設置為此age的值，所有年齡超過此值的對象都會被晉升到老年代，此舉可能會導致老年代需要不少空間應對此種晉升。
一般這個值不需要額外調整。

調優建議

不要手動設置新生代和老年代的大小，只設置這個堆的大小 G1收集器在運行過程中，會自己調整新生代和老年代的大小，其實是通過adapt代的大小來調整對象晉升的速度和年齡，從而達到為收集器設置的暫停時間目標,如果手動設置了大小就意味著放棄了G1的自動調優。

不斷調優暫停時間目標-XX:MaxGCPauseMillis，一般情況下這個值設置到100ms或者200ms，暫停時間設置的太短，就會導致出現G1跟不上垃圾產生的速度。最終退化成Full GC。所以對這個參數的調優是一個持續的過程，逐步調整到最佳狀態。暫停時間只是一個目標，并不能總是得到滿足。

MixedGC調優

-XX:InitiatingHeapOccupancyPercent
-XX:G1MixedGCLiveThresholdPercent
-XX:G1MixedGCCountTarger

適當增加堆內存大小
G1里的Java堆尺寸通常是分區的整數倍。除去這個限制，G1和其他HotSpot垃圾收集器一樣，可以在 -Xms與 -Xmx之間動態地擴大或縮小堆大小。

以下幾種情況，G1可能會增加Java堆尺寸：

在一次full GC中，基于堆尺寸的計算結果會調整堆的空間。

當發生年輕代收集或混合收集，G1會計算執行GC所花費的時間以及執行Java應用所花費的時間。根據命令行配置-XX:GCTimeRatio，如果將太多時間用在垃圾收集上，Java堆尺寸就會增加。這個情況下增加Java堆尺寸，其背后的想法就是允許GC減少發生頻度，這樣與花在應用上的時間相比，花在GC上的時間也可以隨之降低。

G1中-XX:GCTimeRatio的缺省值為9，而其他所有HotSpot垃圾收集器都缺省使用99。GCTimeRatio的值越大，Java堆尺寸的增長就會更加得積極。其他HotSpot收集器在增加Java堆尺寸的策略上會更加激進，因為它們的目標是：相對于執行應用的開銷，用于GC的時間越少越好。

如果一個對象分配失敗了（甚至是在做了一次GC之后），G1會嘗試通過增加堆尺寸來滿足對象分配，而不是馬上退回去做一次full GC。

如果一個巨型對象分配無法找到足夠的連續分區來容納這個對象，G1會嘗試擴展Java堆來獲得更多可用分區，而不是做一次full GC。

當GC需要一個新的分區來轉移對象時，G1更傾向于通過增加Java堆空間來獲得一個新的分區，而不是通過返回GC失敗并開始做一次full GC來找到一個可用分區。

總結

以上是生活随笔為你收集整理的G1GC参数说明的全部內容，希望文章能夠幫你解決所遇到的問題。

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