CMS-GC收集器JVM

CMS收集器

基于标记-清除算法

大体介绍

CMS（Concurrent Mark Sweep） 收集器

1、是一种获取最短回收时间为目标的收集器

2、目前很大一部分的Java应用集中在互联网网站或者基于浏览器的B/S 这些通常较为关注 相应速度

系统停顿的时间尽可能短 体验不好我们都该骂了

1）初始化标记 CMS initial mark

​ 初始化标记 仅仅标记GC ROOTs 能直接关联到对的对象 速度很快

2）并发标记 CMS concurrent mark

​ 并发标记阶段就是从GC ROOTs的直接关联对象开始遍历整个对象图过程 这个过程消耗时长较长但是不需要停顿用户线程可以与垃圾收集线程一起并发运行

3）重新标记CMS remark

​ 重新标记是为了修正并发期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记（可达性分析过程中，对象是否引用变灰，变黑，白色是否没变化，对卡片的收集是否有变化） 就是对发生变化的进行更新操作，这个时间长度远远比并把标记阶段时间短

4）并发清除 CMS concurrent sweep

​ 最后是并发清除阶段，清除删除标记阶段判断的已经死亡的对象 由于不需要移动存活对象 这个阶段也可以用户线程并发进行

注意点：

1、其中 初始化标记 和重新标记这两个需要 Stop the world，全部用户线程得停止留给垃圾收集器进行垃圾收集线程

2、耗时最长的是 并发标记 和并发清除

3、CMS收集器的回收过程是与用户线程一起并发执行的

优点：并发收集，低停顿 又称并发低停顿收集器

缺点及原因：

1、CMS收集器大队处理器资源要求非常敏感

​ 并发阶段不会因为占用处理器核心数资源多而停顿，但是对整个处理器 会变慢 而且吞吐量变小

如果是一共4个及以上处理器 会占用不超过25%的资源 并随着核心处理器的数量增加而变低

如果没有四个<4那可就 占的CPU处理资源是一笔不小的开销 本身处理的内容就很多还要拿出50%左右去处理垃圾回收线程 那负载就很大，为了缓解这个情况 又想出增量式并发收集器 抢占的思想 使用交替进行 从而减少垃圾收集线程所独占的资源时间 整个垃圾收集时间变长 对用户影响会降低 直观又变低了 现在这种已经被抛弃了

2、无法处理浮动垃圾 当处理的时候 这些垃圾还没被标记 或者标记还没有结束。老年代几乎被填满了再去收集

解决方法是：

​ 设置阀值 当达到 或者临界阀值 就启动回收

3、基于标记清除 会有大量的内存碎片产生，给新的对象分配内存的时候由于碎片化，无法满足要求对象大小要求 还要将这些碎片收集整理 启动 Full GC回收机制 就会使整个整个收集过程停顿，

目前对此解决是：

​ 多次进行CMS不整理整理full gc， 当下一次进行full GC的时候开始就进行整理

目前对此解决是：

​ 多次进行CMS不整理整理full gc， 当下一次进行full GC的时候开始就进行整理