JVM学习五.CMS垃圾处理器介绍

CMS垃圾收集器

目的：
以获取最短回收停顿时间为目标的收集器。
应用场景：
互联网站或者B/S系统的服务端上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短，以给用户带来最好的体验。
CMS垃圾收集器运作过程

1. 初始标记：

需要STW(Stop the world)！
标记一下GC Roots 能直接关联到的对象，速度很快。

2. 并发标记：

无需STW，和应用程序一起并发执行。
进行GC Roots Tracing的过程。

3. 重新标记：

需要STW(Stop the world)
为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。
这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间要短。

4. 并发清除：

无需STW，和应用程序一起并发执行。

我们总结下来：初始标记和重新标记需要STW,而并发标记和并发清除并不需要STW.
其次：初始标记和重新标记执行时间较短，而并发标记与清除时间较长。
CMS垃圾收集器的一些缺点，从我们上面给大家介绍，大家也可以感知到一些。
1.CMS收集器对CPU资源非常敏感。
此话怎讲呢？
在并发阶段：它虽然不会导致用户线程暂停，但是它总是要线程去执行的呀，多少会占用点CPU资源。它的默认启动的回收线程数（CPU数量+3）/4,约等于25%。但是当你只有两个CPU的时候，它要占一半CPU资源，这个时候用户响应的吞吐量会下降，对于这种情况咋处理呢？我觉得吧，升级CPU资源吧！
2.无法处理“浮动垃圾”
啥叫浮动垃圾？
CMS在执行并发清楚的时候，你应用系统也在执行，也会产生新的垃圾，但是这一部分垃圾出现在标记过程之后，CMS就无法处理他们，没办法呀！只好等下次执行GC时再清理。
所以这样也引出一个问题，就是CMS不能等我们的老年代填满之后再执行，因为我边执行清除过程，应用也边产生垃圾。那就需要设置一个百分比来确保程序的可执行，避免CMS运行时，预留的内存无法满足程序的需要。
在JDK1.5中，这个百分比为68%，到1.6时，这个参数值提高到了92%。
那如果万一有些人说我就要把这个参数值设置100%，咋办？
那执行的时候内存满了，用户的线程运行不了。
这时候会临时启用serial Old （单线程执行，会暂停所有用户的线程）收集器来重新进行老年代的垃圾收集，这样停顿时间就更长了。
等着被老板拉去小会议室吧！
3.标记-清除算法的硬伤
如果大家对标记-清除算法有概念的话，也就会清楚了。
标记清楚算法执行结束之后会产生大量的空间碎片。
空间碎片过多时，将会个大对象的分配带来很大麻烦，这个时候老年代往往还有很大的空间剩余，但是无法找到足够大的内存来分配空间。
解决方案：
设计者在设计过程中肯定也想到了，设计者提供了一个开关参数：UseCMSCompactAtFullCollection参数，用于CMS顶不住时要不要执行合并整理过程，当然这个过程是无法并发的，这样一来空间碎片问题没有了，但是停顿时间变得更长了。
以上就是CMS垃圾收集算法的一些介绍。

参考来源：《深入理解Java虚拟机》 第二版