CMS 收集器的过程

[size=medium]HotSpot JVM 的并发标记清理收集器 (CMS 收集器) 的主要目标就是：低应用停顿时间。该目标对于大多数交互式应用很重要，比如 web 应用。[/size]

[size=x-large][b]CMS 收集器的过程[/b][/size]

[size=medium]CMS 收集器的 GC 周期由 6 个阶段组成。其中 4 个阶段 (名字以 Concurrent 开始的) 与实际的应用程序是并发执行的，而其他 2 个阶段需要暂停应用程序线程。
[b]1.初始标记[/b]：为了收集应用程序的对象引用需要暂停应用程序线程，该阶段完成后，应用程序线程再次启动。
[b]2.并发标记：[/b]从第一阶段收集到的对象引用开始，遍历所有其他的对象引用。
[b]3.并发预清理：[/b]改变当运行第二阶段时，由应用程序线程产生的对象引用，以更新第二阶段的结果。
[b]4.重标记：[/b]由于第三阶段是并发的，对象引用可能会发生进一步改变。因此，应用程序线程会再一次被暂停以更新这些变化，并且在进行实际的清理之前确保一个正确的对象引用视图。这一阶段十分重要，因为必须避免收集到仍被引用的对象。
[b]5.并发清理：[/b]所有不再被应用的对象将从堆里清除掉。
[b]6.并发重置：[/b]收集器做一些收尾的工作，以便下一次 GC 周期能有一个干净的状态。

一个常见的误解是, CMS 收集器运行是完全与应用程序并发的。我们已经看到，事实并非如此，即使 “stop-the-world” 阶段相对于并发阶段的时间很短。

应该指出，尽管 CMS 收集器为老年代垃圾回收提供了几乎完全并发的解决方案，然而年轻代仍然通过 “stop-the-world” 方法来进行收集。对于交互式应用，停顿也是可接受的，背后的原理是年轻带的垃圾回收时间通常是相当短的。
[/size]

[url]http://wiki.jikexueyuan.com/project/jvm-parameter/cms.html[/url]