CMS升級為G1方式

計算中心“生產全部服務實體部署的服務器，使用的是JDK1.8，JDK1.8支持G1垃圾回收器，故將服務啟動引數進行統一調整：

1）原引數（主要問題：使用CMS版本，JDK1.7，1.8引數混用，未指定堆外記憶體大小）

/opt/java/jdk1.8.0_102/bin/java -Dapp.home=${APP_HOME} -Dspring.profiles.active=prd -Dserver.port=${SERVER_PORT} -server -Xms4G -Xmx4G -Xmn2g -Xss256k -XX:PermSize=128m -XX:MaxPermSize=512m -Djava.awt.headless=true -Dfile.encoding=utf-8 -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:AutoBoxCacheMax=20000 -XX:-OmitStackTraceInFastThrow -XX:ErrorFile=${APP_HOME}/logs/hs_err_%p.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${APP_HOME}/logs/ -Xloggc:${APP_HOME}/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -jar ${APP_HOME}/webapps/${JAR_NAME} ${SERVER_PORT}"

2）新引數（使用G1做為垃圾回收器）

/opt/java/jdk1.8.0_102/bin/java -Dapp.home=${APP_HOME} -Dspring.profiles.active=prd -Dserver.port=${SERVER_PORT} -server -Xms4g -Xmx4g -Xss256k -XX:NewSize=512m -XX:MaxNewSize=512m -XX:+UseG1GC -XX:InitiatingHeapOccupancyPercent=40 -XX:G1HeapRegionSize=8m -XX:+ExplicitGCInvokesConcurrent -XX:ParallelGCThreads=4 -Dsun.rmi.dgc.server.gcInterval=36000000-Dsun.rmi.dgc.client.gcInterval=36000000-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -XX:+UseCodeCacheFlushing -XX:ReservedCodeCacheSize=256m -XX:MaxDirectMemorySize=512m -XX:GCTimeRatio=19 -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=30 -XX:ErrorFile=${APP_HOME}/logs/hs_err_%p.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${APP_HOME}/logs/ -Xloggc:${APP_HOME}/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -jar ${APP_HOME}/webapps/${JAR_NAME} ${SERVER_PORT}"

注：不同服務器環境，不同容器，腳本配置各不相同，要在對應腳本的基礎上進行針對性升級，

生產G1回收器主要引數說明

JVM相關概念說明

JDK1.7記憶體模型

實際占用記憶體大小(引數)：-XX:MaxPermSize(非堆) + -Xmx(堆) + -Xss(堆疊) + -XX:MaxDirectMemorySize(堆外)

JDK1.8記憶體模型

實際占用記憶體大小(引數)：-XX:MaxMateSpaceSize(堆外) + -Xmx(堆) + -Xss(堆疊) + -XX:MaxDirectMemorySize(堆外)

GC流程圖

1、什么時候觸發Minor GC

2、觸發Minor GC 的程序

3、Full GC 的程序

1、新創建的物件一般會被分配在新生代中，常用的新生代的垃圾回收器是 ParNew 垃圾回收器，它按照 8:1:1 將新生代分成 Eden 區，以及兩個 Survivor 區，創建的物件將 Eden 區全部擠滿，這個物件就是「擠滿新生代的最后一個物件」，此時，Minor GC 就觸發了，

2、在正式 Minor GC 前，JVM 會先檢查新生代中物件，是比老年代中剩余空間大還是小，Minor GC 之后 Survivor 區放不下剩余物件，這些物件就要進入到老年代，所以要提前檢查老年代是不是夠用，

3、老年代剩余空間大于新生代中的物件大小，那就直接 Minor GC，GC 完 survivor 不夠放，老年代也絕對夠放，老年代剩余空間小于新生代中的物件大小，這時候就要進入老年代空間分配擔保規則，

4、老年代空間分配擔保規則：如果老年代中剩余空間大小，大于歷次 Minor GC 之后剩余物件的大小，那就允許進行 Minor GC，因為從概率上來說，以前的放的下，這次的也應該放的下，那就有兩種情況：

• 老年代中剩余空間大小，大于歷次 Minor GC 之后剩余物件的大小，進行 Minor GC

• 老年代中剩余空間大小，小于歷次 Minor GC 之后剩余物件的大小，進行 Full GC，把老年代空出來再檢查，

• 結合第四步，開啟老年代空間分配擔保規則只能說是大概率上來說，Minor GC 剩余后的物件夠放到老年代，如果放不下：Minor GC 后會有這樣三種情況：

• Minor GC 之后的物件足夠放到 Survivor 區，GC 結束，

• Minor GC 之后的物件不夠放到 Survivor 區，接著進入到老年代，老年代能放下，那也可以，GC 結束，

• Minor GC 之后的物件不夠放到 Survivor 區，老年代也放不下，那就只能 Full GC，

• 以上是成功 GC 的例子，以下3 中情況，會導致 GC 失敗，報 OOM：

緊接上一節 Full GC 之后，老年代任然放不下剩余物件，就只能 OOM，
未開啟老年代分配擔保機制，且一次 Full GC 后，老年代任然放不下剩余物件，也只能 OOM，
開啟老年代分配擔保機制，但是擔保不通過，一次 Full GC 后，老年代任然放不下剩余物件，也是能 OOM，
注：

• 老年代分配擔保機制在JDK1.5以及之前版本中默認是關閉的，需要通過HandlePromotionFailure手動指定，JDK1.6之后就默認開啟，如果我們生產環境服務使用的是JDK/1.7JDK1.8，所以不用再手動去開啟擔保機制，
• Full GC主要指新生代、老年代、metaspace上的全部GC，

感謝以下作者給與我的幫助

• 圖解GC流程:https://www.cnblogs.com/shuiyj/p/12640692.html
• CMS垃圾回收升級G1回收器實踐:http://arick.net/content/44
• JAVA常見問題分析：https://blog.51cto.com/hmtk520/2067043