CMS垃圾回收期详解

CMS

1.CMS

​ CMS是一种已获取最短回收停顿时间为目标的收集器。出发点是java应用集中在互联网网址或者基于浏览器的B/S系统

的服务器上，这类应用通常关注服务的响应速度，希望系统停顿时间尽可能短，已给用户更好的交互体验

​ CMS在名称中就包含了其垃圾回收的理念，MS（Mark Sweep）标记清除算法。

1.1 cms的处理过程

1. 初始标记：仅仅标记一些GCROOTS直接关联的对象，STW（停顿时间），很短
2. 并发标记：从GCROOTS的直接关联对象开始，遍历整个对象图的过程
3. 重新标记：修正在并发标记期间，因用户程序继续运作而导致标记变动的那一部分的对象标记记录，STW
4. 并发清除：清理调标记阶段判断的已经死亡的对象

为什么要进行重新标记？

1. 可能在并发标记的过程中，用户线程将应用链上的对象修改了，该对象被修改了，这会导致这次垃圾回收不能处理该对象，但是这是比较好处理的，下次垃圾回收时在处理也不为过

2. 第二种就是必须避免的情况，在并发标记和用户线程并发执行的过程中

   • 扫描过改点后，该点新指向了一个对象
   • 扫描改点时，应用链断开，但是该对象连接上了前一个点

   上述两点都会造成对象的丢失，因此需要一个重新标记的过程，

   ​ 关于第一点，解决方案是增量更新，及改点在插入新的引用关系时，将这个新插入的引用记录下来，等并发扫描结束后，再将这些节点作为黑色对象沿着引用链进行扫描

   ​ 第二点，采用原始快照的方式，当灰节点要删除应用链时，将这个应用关系记录下来，重新标记时再一次扫描。

   G1同样采用的这种方式，后续不做再开讲述。

CMS默认启动的回收线程数（处理器核心数量+3）/ 4

当cpu处理器和兴数较少时，采用“增量式并发收集器”

1.2 存在的问题

​ 并发处理和并发标记时会产生“浮动垃圾”，在程序并发运行过程中，可能会对一些对象进行修改，产生新的垃圾，这一部分垃圾不会在这一次清除时解决，留到下一次。同时在用户线程运行过程中，还需要使用内存，也需要流出一部分内存空间来给用户线程使用。

​ 因此，CMS不能像其他线程那样等到老年代使用完后，在进行垃圾回收，必须留出已一部分空间给程序运行使用

​ JDK1.5默认设置为超过68%，进行垃圾回收，JDK1.6 92%

​ 如果在实际应用中老年代的增长不是太快，可以适当调高参数-XX:CMSInitiatingOccu-pancyFraction

​

​ 还有一个问题就是，标记清除算法本身造成的，大量的空间碎片导致垃圾回收后，没有足够的空间存储新对象，不得不触发fullgc，并在fullgc时开启内存碎片整理。这个会造成大量的停顿时间

​ -XX:CMSFullGCBeforeCompaction这个参数是CMS收集器在执行若干次后，下次进入fullgc之前会进行内存碎片整理。

参考

1. 《深入理解java虚拟机》 周志明
2. https://blog.youkuaiyun.com/qq_32165517/article/details/106551809