java 优于 c++ 的一个亮点就是自动的垃圾回收机制，成也萧何败萧何，最困扰 java 程序员的问题往往又都和垃圾回收机制有关，作为一个 java 程序员，如果你不了解 java 垃圾回收的机制，那么你时刻都可能面临性能的瓶颈，甚至遇到种种诡异的问题而无从下手。
此前，我们已经介绍过 java 垃圾回收相关的很多内容：
本文我们就来详细介绍一个 java 中明星级的垃圾回收器 CMS 的回收机制，而新一代的 G1 回收器的执行机制会在下一篇文章中再来介绍，敬请期待。
CMS 是 Concurrent Mark Sweep 的缩写，是现在主流十分常用的老年代垃圾回收器，他的主要目标是用最短的回收停顿时间实现老年代的清理，因此，对于强调用户体验的互联网应用来说，CMS 成为了一个首选。
那么，CMS 垃圾回收器究竟是怎么工作的呢？
CMS 垃圾回收器采用了标记清除算法来实现。
说到“标记-清除”算法，顾名思义，jvm 将整个收集过程划分为了“标记”与“清除”两大步骤来实现。
具体到标记流程，jvm 采用了“三色标记法”，就是将不同的对象划分为三大类：
我们知道，jvm 是通过可达性分析法来实现标记过程的，jvm 从 GC Root 开始，逐步遍历引用树来实现对内存区域内每个对象的标记，可以参看：
java 对象存活判定算法
一般来说，人们通常把 CMS 的执行过程分为四个步骤：
加上可选的阶段，CMS 回收的过程可以划分为七个步骤，下面我们就来详细介绍：
如上所述，初始标记最重要的工作就是以 GC-Roots 为起点进行可达性分析，标记出所有当前活跃的也就是被引用的对象。
但是，除了被 GC-Root 引用外，老年代中的对象如果仅被年轻代中的对象引用，他也是不能回收的，因此，在上述以 GC-Roots 为起点进行的标记完成后，还需要遍历新生代对象，标记可达的老年代对象。
由于上述两个过程仅仅遍历被 GC-Roots 和新生代对象直接引用的老年代对象，执行起来速度会非常快，为了避免在标记过程中对象引用的动态变化，在初始标记阶段，程序需要进行短暂停止，这称为“Stop The World”。
jdk8 以后，初始标记支持多线程标记，可以通过 CMSParallelInitialMarkEnabled 参数开启。
“并发标记”阶段所谓的“并发”，指的就是用户线程可以与回收线程同步执行，而不需要让用户线程暂停，从而保证了用户线程的执行效率。
初始标记的过程中，为了尽量缩短用户线程的暂停时间，所以仅对被 GC-Roots 和新生代对象直接引用的老年代对象进行了标记，所以，接下来的一项工作就是对 GC-Roots 和新生代对象间接引用的老年代对象进行标记，这就是并发标记阶段的主要工作了。
4.2.1 如何处理并发标记阶段的引用关系变更
由于在并发标记阶段，用户线程与回收线程并发执行，随时可能有新生代的对象晋升到老年代、直接在老年代分配对象或者引用关系发生变更等等情况发生，这些情况下，jvm 是否必须扫描整个老年代才能够识别出这些发生了变化的对象呢？
答案当然是否定的，HotSpot 使用了一套名叫“卡表”（Card Table）的数据结构来管理老年代的内存，Card Table 实际上就是一个索引列表，每一个表项占用 1 byte 空间，索引内存中占 512 byte 的页空间。
而在对每一个对象引用进行写操作之前和之后 HotSpot 都附加了一定的逻辑，称之为“写屏障”(Write Barrier)，写屏障会在一个对象的引用发生变化时，将该对象所在的页在卡表中对应的表项标记为 dirty。
但是，由于 jvm 中对象引用变更是极为频繁的，反复读写卡页显然会有很大的性能开销，于是，从 JDK7 开始，HotSpot 引入了一个新的 JVM 参数 -XX:+UseCondCardMark，从而让已经标记过的卡页不再重复标记。
这一步是可选的，可以通过参数 CMSPrecleaningEnabled 参数可以启用或关闭该阶段，默认是开启的。
上文已经介绍到，在并发标记阶段，由于引用的变更，可能会产生一些 dirty page，这一阶段的主要工作就就是处理这些脏页，虽然在后面的重新标记阶段也拥有处理脏页的逻辑，但重新标记阶段会 Stop The World，所以这一阶段的核心仍然是让停顿时间尽量缩短。
这一阶段的主要工作是处理新生代指向老年代的新引用，从而让老年代的一些未被标记的对象成为活跃对象。
同样，在重新标记阶段也会处理这样的情况，这一阶段仍然是为了缩短停顿时间而进行的。
CMS 对于该阶段有以下 4 个参数：
显然，在这一阶段中要识别新生代对象对老年代对象的新引用，那么就必须扫描整个新生代，这显然是一项很耗时的操作，但由于新生代的对象大多是朝生夕死的，所以如果在一次 minorGC 之后紧接着进行一次预清理，新生代中需要扫描的对象就会所剩无几了。
CMS 通过 CMSScavengeBeforeRemark 参数强制在可中断的并发预清理阶段执行一次 minorGC，虽然 minorGC 也会让用户线程短暂停顿，但这样可以缩短下一阶段的停顿时间，整体上还是利大于弊的。
在上述的并发过程中，用户线程始终在执行，因此随时可能会产生引用变更，比如：
这些情况下，很有可能造成标记数据的不准确，如果直接进行清理，就有可能有误清理的情况发生，因此，jvm 需要再一次 Stop The World 来进行重新标记，从而保证在真正的清理前，标记的准确性。
重新标记阶段，jvm 主要进行以下三个工作：
但由于有了前面三个步骤的反复标记过程，重新标记阶段的工作量已经被大大降低，停顿时间当然也因此大大减少。
完成了标记工作，就只剩下最后的一步工作，那就是清除了。
由于被清除的对象都是未被使用的对象，因此在清楚操作进行中，是不需要 Stop The World 的，这一步操作也是和用户线程同步执行的。
完成了整个 CMS 的标记-清除工作后，需要将 CMS 算法的内部数据进行重置，从而让下一次 GC 顺利开始。
下面是一次 CMS 进行 Full GC 的完整日志，我们可以清楚的看到每一阶段的运行信息与耗时情况：