CMS的Full GC採用壓縮式垃圾收集，在堆比較大的時候，如果full gc頻繁，會導致停頓，並且呼叫方阻塞、超時、甚至雪崩的情況出現，所以降低full gc的發生頻率和需要時間，非常有必要。

目標

• 減少full gc頻率
• 減少ygc和full gc時間

優化

配置變化

優化前

<jvm-arg>-Xmx13312m</jvm-arg>
<jvm-arg>-Xms9216m</jvm-arg>
<jvm-arg>-Xmn1024m</jvm-arg>
<jvm-arg>-XX:PermSize=512M</jvm-arg
 
>
<!-- 使用cms回收策略 -->
<jvm-arg>-XX:+UseParNewGC</jvm-arg>
<jvm-arg>-XX:+UseConcMarkSweepGC</jvm-arg>
<!-- 列印gc日誌 -->
<jvm-arg>-XX:+PrintGCDetails</jvm-arg>
<jvm-arg>-XX:+PrintGCDateStamps</jvm-arg>
<jvm-arg>-XX:+PrintHeapAtGC</jvm-arg
 
>
<jvm-arg>-Xloggc:log/gc.log</jvm-arg>

優化後：

<jvm-arg>-Xmx13312m</jvm-arg>
<jvm-arg>-Xms13312m</jvm-arg>
<jvm-arg>-Xmn5120m</jvm-arg>
<jvm-arg>-XX:PermSize=512M</jvm-arg>
<jvm-arg>-XX:+UseParNewGC</jvm-arg>
<jvm-arg>-XX:+UseConcMarkSweepGC</jvm-arg
 
>
<!-- 每次full gc之後，進行壓縮 -->
<jvm-arg>-XX:CMSFullGCsBeforeCompaction=0</jvm-arg>
<!-- 老年代佔用75%進行full gc -->
<jvm-arg>-XX:CMSInitiatingOccupancyFraction=75</jvm-arg>
<jvm-arg>-XX:CMSMaxAbortablePrecleanTime=30000</jvm-arg>
<jvm-arg>-XX:SurvivorRatio=6</jvm-arg>
<jvm-arg>-XX:+PrintGCDetails</jvm-arg>
<jvm-arg>-XX:+PrintGCDateStamps</jvm-arg>
<jvm-arg>-XX:+PrintHeapAtGC</jvm-arg>
<jvm-arg>-Xloggc:log/gc.log</jvm-arg>

第一次優化

將Xmx和Xms設定為一樣大小，調大Xmn

原因

• 將Xmx和Xms設定為一樣大小，沒有必要達到Xms後，再申請Xmx

調整以下引數

<jvm-arg>-Xmx13312m</jvm-arg>
<jvm-arg>-Xms13312m</jvm-arg>
<jvm-arg>-Xmn4096m</jvm-arg>

效果 ygc由每分鐘40次，降低為10次上下 fgc時間，由之前的100ms升為300ms

第二次優化

時間一長，發現單次full gc時間太長，有時候長達2s，日誌中發現pre clean沒有結束，就進行了remark導致的。

 CMS: abort preclean due to time 2016-06-13T08:58:07.672+0800: 63803.570: [CMS-concurrent-abortable-preclean: 5.190/5.211 secs] [Times: user=12.15 sys=1.38, real=5.21 secs] 
2016-06-13T08:58:07.677+0800: 63803.575: [GC[YG occupancy: 2652667 K (3774912 K)]63803.576: [Rescan (parallel) , 1.9969650 secs]63805.573: [weak refs processing, 0.0280880 secs] [1 CMS-remark: 7082120K(9437184K)] 9734787K(13212096K), 2.
0288350 secs] [Times: user=25.39 sys=0.11, real=2.03 secs]

pre clean用於保證remark的順利進行，如果pre clean階段沒有結束，就remark，會導致remark階段延長，pre clean預設是5s，延長至30s。 調整以下引數：

 -XX:CMSMaxAbortablePrecleanTime=30000

效果 優化後，日發gc日誌中沒有abort preclean的現象發生了。

第三次優化

前兩次優化已經見到效果了，但是full gc還是比較多，且持續時間比較長，增加配置，列印物件年齡：

-XX:+PrintTenuringDistribution

因為通過ygc的物件進入老年代，是按照年齡計算的，這個年齡預設是15，但是是動態調整的，所以加這個引數，再觀察一下。 檢視日誌可以看出，物件動態調整年齡是4，太低了，物件才4歲，就進入老年代了。

2016-06-14T19:51:31.639+0800: 770.958: [GC 770.959: [ParNew
Desired survivor size 214728704 bytes, new threshold 4 (max 4)
- age   1:   27368432 bytes,   27368432 total
- age   2:   12108344 bytes,   39476776 total
- age   3:   11933416 bytes,   51410192 total
- age   4:    5568312 bytes,   56978504 total

預設配置的15，怎麼才4就進入老年代了，原來jvm是動態物件年齡判定的。

為了能更好地適應不同程式的記憶體狀況，虛擬機器並不總是要求物件的年齡必須達到Max Tenuring Threshold才能晉升老年代

如果在Survivor空間中相同年齡所有物件大小的總和大於Survivor空間的一半，年齡大於或等於該年齡的物件就可以直接進入老年代，無須等到Max Tenuring Threshold中要求的年齡。

既然取決於survivor的大小，調大survivor

修改配置：

-Xmn5120m
-XX:SurvivorRatio=6

調整後，age已經到15了。

2016-06-15T10:11:28.921+0800: 631.926: [GC 631.927: [ParNew
Desired survivor size 335544320 bytes, new threshold 15 (max 15)
- age   1:   44556600 bytes,   44556600 total
- age   2:   41122176 bytes,   85678776 total
- age   3:   14339240 bytes,  100018016 total
- age   4:   19359008 bytes,  119377024 total
- age   5:   13662592 bytes,  133039616 total
- age   6:   21144880 bytes,  154184496 total
- age   7:   17551328 bytes,  171735824 total
- age   8:    5390312 bytes,  177126136 total
- age   9:    8580176 bytes,  185706312 total
- age  10:    7921328 bytes,  193627640 total
- age  11:   17954784 bytes,  211582424 total
- age  12:    6197064 bytes,  217779488 total
- age  13:    7211632 bytes,  224991120 total
- age  14:   10837872 bytes,  235828992 total
- age  15:   10255800 bytes,  246084792 total
: 4236533K->288272K(4587520K), 0.0551150 secs] 4916941K->973217K(12976128K), 0.0557070 secs] [Times: user=0.80 sys=0.01, real=0.06 secs] 
Heap after GC invocations=68 (full 1):

效果

• full gc由高峰期平均10分鐘一次，減少到平均1小時一次
• ygc 由高峰期平均每分鐘40次，減少為平均每分鐘8次
• ygc由高峰期耗時由1.5s，減少為平均500ms
• 非高峰期，幾乎沒有full gc
• full gc高峰期耗時有所增長，由原來的不到100ms，增長為400ms，調整堆大小了嘛

參考資料