### CMS收集器(Concurrent Mark Sweep) **CMS收集器(Concurrent Mark Sweep) **是一種以獲取最短回收停頓時間為目標的收集器 JDK1.5時，HotspotVM推出一款在強交互應用中可認為有劃時代意義的垃圾收集器CMS（Concurrent-Mark-sweep）。CMS是HotspotVM中第一款真正意義上的并發垃圾收集器，第一次實現了讓垃圾收集線程與用戶線程可同時工作。 CMS關注點是盡可能縮短垃圾收集時用戶線程的停頓時間，停頓時間越短就越適合與用戶交互的場景。 CMS使用的是標記-清除算法，針對老年代的垃圾回收 無法與新生代垃圾回收器Parallell Scavenge組合使用，使用CMS時只能和ParNew或者時Serial配合使用。 JDK9中CMS被標記為廢棄，JDK14中正式被移除 #### 特性 * 目標：獲取最短回收停頓時間 * 適用于互聯網B/S系統服務端 * 基于“標記-清除”算法實現 * 也稱為并發低停頓收集器 * JDK1.5默認設置下CMS收集器當老年代使用了68%的空間后就會被激活 * JDK1.6CMS收集器的啟動閾值提升至92% * 如果CMS運行期間預留的內存無法滿足應用程序需要，就會出現一次"Concurrent Mode Failure"失敗，此時將啟動后備預案：臨時啟用Serial Old收集器重新進行老年代的垃圾收集 #### 內存碎片化 由于CMS使用的是標記-清除算法，對存活對象沒有進行地址的移動，所以回收對象之后就會產生內存碎片化（可用內存不連續），對于分配一些較大內存對象內存空間的時候就很尷尬，且內存的不連續也不能使用指針碰撞技術，只能使用空閑列表來進行內存的分配 #### 優缺點 * 優點:并發收集、低延遲、低停頓 * 缺點: 1.對CPU資源非常敏感：在并發階段雖然不會造成STW的發生，但是會因為其垃圾回收線程占用的服務器資源導致程序變慢，總的吞吐量將會有一定的降低 2.無法處理浮動垃圾(Floating Garbage)：在并發標記的階段中，如果產生新的垃圾對象，CMS將無法對這些垃圾進行識別標記（從GC Roots直接關聯對象出發遍歷整個對象引用結構），就會導致這一部分的垃圾沒有被及時的回收掉。只能在下一次執行GC的時候對這一部分垃圾進行處理 3.“標記-清除”算法會產生大量空間碎片，大對象無法存放發生后，不得不提前的觸發Full GC #### CMS"標記-清除"算法實現 1. 初始標記(CMS initial mark) 2. 并發標記(CMS concurrent mark) 3. 重新標記(CMS remark) 4. 并發清除(CMS concurrent sweep) **說明：**初始標記、重新標記仍然需要Stop The World #### 相關參數 * \-XX:+UseConcMarkSweepGC：手動指定使用CMS，開啟CMS之后，會自動將ParNew打開，即-XX:+UseParNewGC，此時JVM垃圾回收將會是**ParNew（新生代）+CMS（老年代）+Serial Old（CMS的后備）**的組合。 * \-XX:+CMSInitiatingOccupanyFraction：設置堆內存使用率閾值，一旦達到該設置的閾值，CMS將會開啟進行垃圾回收。 * JDK5默認值為68。即68%，JDK6以上默認值為92 * **如果內存增長的較慢，可以增大該閾值，降低CMS的觸發頻率，如果內存增長較快，要適當的減小該閾值，以免觸發Serial Old串行垃圾回收器，減少Full GC的次數**。 * \-XX:+UseCMSCompactAtFullCollection：用于CMS在垃圾回收之后對內存碎片進行整理，這個過長將會存在STW。 * \-XX:+CMSFullGCsBeforeCompaction：設置在執行多少次FullGC后對內存空間進行壓縮整理，和-XX:+UseCMSCompactAtFullCollection搭配使用。 * \-XX:ParallelCMSThreads：設置CMS的線程數量，CMS默認線程數量為（**ParallelGCThreads**\+ 3）/ 4。**ParallelGCThreads是年輕代并行收集器Parallel的線程數**