CMS 收集器實戰

最新2020整理收集的一線互聯網公司面試真題（都整理成檔案），有很多干貨，包含netty，spring，執行緒，spring cloud等詳細講解，也有詳細的學習規劃圖，面試題整理等，我感覺在面試這塊講的非常清楚:獲取面試資料只需:點擊這里領取!!! 暗號：CSDN

實戰開始，準備好了沒

模擬業務場景代碼：

@RestController
public class IndexController {
/***
 * 存 big 物件
 * @return
 */
@GetMapping("/put")
public String process() {
   ArrayList<User> users = queryUsers();
   for (User user:users){
      //TODO 業務操作
   }
   return "ok";
}
private ArrayList<User> queryUsers() {
   ArrayList<User> users = new ArrayList<>();
   for (int i = 0; i < 50000; i++) {
      users.add(new User(i, "java2b"));
   }
   return users;
}
}

public class User {

   private int id;
   private String name;
   private byte[] data;

   public User(int id, String name) {
      this.id = id;
      this.name = name;
      data=new byte[1 * 128 * 1024];
   }
}

輸出收集器資訊：

/***
 * 列印 jvm 資訊
 * @return
 */
@GetMapping("/info")
public String info() {
   List<GarbageCollectorMXBean> garbages = ManagementFactory.getGarbageCollectorMXBeans();
   StringBuilder stringBuilder = new StringBuilder();
   for (GarbageCollectorMXBean garbage : garbages) {
      stringBuilder.append("垃圾收集器：名稱=" + garbage.getName() + ",收集=" + garbage.getCollectionCount() + ",總花費時間="
              + garbage.getCollectionTime());
      // + ",記憶體區名稱=" + Arrays.deepToString(garbage.getMemoryPoolNames()));
      stringBuilder.append("\r\n");
   }
   MemoryMXBean memory = ManagementFactory.getMemoryMXBean();
   MemoryUsage headMemory = memory.getHeapMemoryUsage();
   long MB = 1024 * 1024;
   stringBuilder.append("head 堆:");
   stringBuilder.append("\t 初始(M):" + headMemory.getInit() / MB);
   stringBuilder.append("\t 最大(上限)(M):" + headMemory.getMax() / MB);
   stringBuilder.append("\t 當前(已使用)(M):" + headMemory.getUsed() / MB);
   stringBuilder.append("\t 提交的記憶體(已申請)(M):" + headMemory.getCommitted() / MB);
   stringBuilder.append("\t 使用率:" + headMemory.getUsed() * 100 / headMemory.getCommitted() + "%");
   return stringBuilder.toString();
}

生成 jar 包部署到服務器
啟動引數：

 java -Xms256m -Xmx256m -verbose:gc -Xloggc:/root/jvm/gc-cms.log -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintHeapAtGC -XX:HeapDumpPath=/root/jvm/dump.hprof -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCTimeStamps -XX:+PrintCommandLineFlags -XX:+PrintFlagsFinal -XX:+PrintGCDetails -XX:+UseCMSCompactAtFullCollection -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.port=6666 -Djava.rmi.server.hostname=192.168.0.31 -jar /root/jvm/jvm-web-0.0.1-SNAPSHOT.jar > catalina.out &

這兒要插播下 JVM 引數意義.

JVM 引數詳解：

JVM 引數 含義

-XX:-CMSPrecleaningEnabled
不進行預清理，度過我們之前的文章的都知道，CMS 在并發標記和重新標記的這段時間內，會有一個預清理的作業，而這個通過會嘗試 5 秒之內等待來一次 YGC，以免在后面的重新標記階段耗費大量時間來標記新生代的物件，

-XX:+UseConcMarkSweepGC
此引數將啟動 CMS 回收器，默認新生代是 ParNew，也可以設定 Serial 為新生代收集器，該引數等價于 -Xconcgc，

-XX:ParallelGCThreads
由于是并行處理器，當然也可以指定執行緒數，默認并發執行緒數是：（ParallelGCThreads + 3）/ 4），
-XX:ConcGCThreads
或者 -XX:ParallelCMSThreads ；除了上面設定執行緒的方式，你也可以通過這個兩個引數任意一個手工設定 CMS 并發執行緒數

-XX:CMSInitiatingOccupancyFraction
由于 CMS 回收器不是獨占式的，在垃圾回收的時候應用程式仍在作業，所以需要留出足夠的記憶體給應用程式，否則會觸發 FGC，而什么時候運行 CMS GC 呢？通過該引數即可設定，該引數表示的是老年代的記憶體使用百分比，當達到這個閾值就會執行 CMS，默認是 68， 如果老年代記憶體增長很快，建議降低閾值，避免 FGC，如果增長慢，則可以加大閾值，減少 CMS GC 次數，提高吞吐量，

-XX：+UseCMSCompactAtFullCollection
由于 CMS 使用標記清理演算法，記憶體碎片無法避免，該引數指定每次 CMS 后進行一次碎片整理，

-XX:CMSFullGCsBeforeCompaction 由于每次進行碎片整理將會影響性能，你可以使用該引數設定多少次 CMS 后才進行一次碎片整理，也就是記憶體壓縮，

-XX:+CMSClassUnloadingEnabled
允許對類元資料進行回收，

-XX:CMSInitiatingPermOccupancyFraction

當永久區占用率達到這一百分比時，啟動 CMS 回收（前提是 -XX:+CMSClassUnloadingEnabled 激活了），

-XX:UseCMSInitiatingOccupancyOnly

表示只在到達閾值的時候才進行 CMS 回收，

XX:CMSWaitDuration=2000
由于 CMS GC 條件比較簡單，JVM 有一個執行緒定時掃描 Old 區，時間間隔可以通過該引數指定（毫秒單位），默認是 2s，
JVM 工具引數：
JVM 引數 含義

-XX:+PrintGCDateStamps 列印 GC 日志時間戳
-XX:+PrintGCDetails 列印 GC 詳情
-XX:+PrintGCTimeStamps 印此次垃圾回收距離 jvm 開始運行的所耗時間
-Xloggc: 將垃圾回收資訊輸出到指定檔案
-verbose:gc 列印 GC 日志
-XX:+PrintGCApplicationStopedTime 查看 gc 造成的應用暫停時間
XX:+PrintTenuringDistribution 物件晉升的日志
-XX:+HeapDumpOnOutOfMemoryError 記憶體溢位時輸出 dump 檔案

啟動效果：

訪問：

請求 put： 我們通過 http 訪問 put 方法之后看看效果：

在運行的程序中我們發現有大量的物件進入老年代，觸發了 full gc，cms 一直在收集，

使用率達到 99%，cms 也一刻沒停下：

日志分析

日志分析 1.0 版本： 我們抽取一條日志來分析下

[GC (Allocation Failure) 0K->63K(64K), 0.0047147 secs] 10258K->6780K(46144K), [Metaspace: 3434K->3434K(1056768K)], 0.0047613 secs][Times: user=0.02 sys=0.00, real=0.00 secs] 該日志為四個部分：

Full GC：

表明進行了一次垃圾回收，前面沒有 Full 修飾，表明這是一次 Minor GC ,注意它不表示只 GC 新生代，并且現有的不管是新生代還是老年代都會 STW，

Allocation Failure：

表明本次引起 GC 的原因是因為在年輕代中沒有足夠的空間能夠存盤新的資料了，

10258K->6780K(46144K),：單位是 KB

三個引數分別為：GC 前該記憶體區域(這里是年輕代)使用容量，GC 后該記憶體區域使用容量，該記憶體區域總容量，

0.0047613 secs：

該記憶體區域 GC 耗時，單位是秒

[Times: user=0.04 sys=0.00, real=0.01 secs]：

分別表示用戶態耗時，內核態耗時和總耗時

日志分析 2.0 版本：

采用在線 gceasy 來進行分析，我們打開網址，然后上傳我們生產的 gc 日志，如圖所示：

優化問題：列出了可以優化的 4 個問題新生代和老年代元空間記憶體占用情況

吞吐量統計：97.39%

各各分代的記憶體變化

CMS 垃圾收集器不同時期發生的耗時

GC 發生次數的分類和耗時情況

定位問題

我們通過生產的快照檔案來定位問題：
JProfiler：

下載到本地通過 JProfiler 打開查看
查看大物件
我們不難發現是 ArrayList 集合占用了 96%的記憶體，那我們來看看哪塊代碼大量用到了我們 ArrayList 集合了
找到對應代碼
通過此代碼我們就發現 put 方法大量用到了 ArrayList 集合造成的記憶體溢位 OOM

總結

上述實戰相信大家都明白了，大致流程就是：

1、夠將 SpringBoot 專案 模擬真實大批量用戶場景

2、配置 JVM 引數然后部署運行監控資料生成日志檔案

3、通過分析日志檔案確認問題，
需要上文代碼和軟體的朋友，也有詳細的學習規劃圖，面試題整理等，我感覺在面試這塊講的非常清楚:獲取面試資料只需:點擊這里領取!!! 暗號：CSDN 大家可以自己實操下加深印象，