一步步优化JVM五：优化延迟或者响应时间(3)
CMS垃圾回收器周期
一旦young的空间大小（包含eden和survivor空间）已经完善得满足应用对MinorGC产生延迟要求，注意力可以转移到优化CMS垃圾回收器，降低最差延迟时间的时间长度以及最小化最差延迟的频率。目标是保持可用的old代空间和并发垃圾回收，避免stop-the-world压缩垃圾回收。
stop-the-world压缩垃圾回收是垃圾回收影响延迟的最差情况，对某些应用来说，恐怕无法完全避免开这些，但是本节提供的优化信息至少可以减少他们的频率。
成功的优化CMS垃圾回收器需要达到的效果是old代的里面的垃圾回收的效率要和young代转移对象到old代的效率相同，没有能够完成这个标准可以称为“比赛失败”，比赛失败的结果就是导致stop-the-world压缩垃圾回收。不比赛中失败的一个关键是让下面两个事情结合起来：1、old代有足够的空间。2、启动CMS垃圾回收周期开始时机——快到回收对象的速度比较转移对象来的速度更快。
CMS周期的启动是基于old代的空间大小的。如果CMS周期开始的太晚，他就会输掉比赛，没有能够快速的回收对象以避免溢出old代空间。如果CMS周期开始得太早，会造成不必要的压力以及影响应用的吞吐量。但是，通常来讲过早的启动总比过晚的启动好。
HotSpot VM自动地计算出当占用是多少时启动CMS垃圾回收周期。不过在一些场景下，对于避免stop-the-world垃圾回收，他做得并不好。如果观察到stop-the-world垃圾回收，你可以优化该什么时候启动CMS周期。在CMS垃圾回收中，stop-the-world压缩垃圾回收在垃圾回收日志中输出是“concurrent mode failure”，下面一个例子：
174.445: [GC 174.446: [ParNew: 66408K->66408K(66416K), 0.0000618 secs]174.446: [CMS ( concurrent mode failure): 161928K->162118K(175104K), 4.0975124 secs] 228336K->162118K(241520K)
如果你发现有concurrent mode failure你可以通过下面这个选项来控制什么时候启动CMS垃圾回收：

-XX:+ParallelRefProcEnabled

这个选项可以用HotSpot VM的任何一种垃圾回收器上，他会是用多个的引用处理线程，而不是单个线程。这个选项不会启用多线程运行方法的finalizer。他会使用很多线程去发现需要排队通知的finalizable对象。
下一步
这一步结束，你需要看看应用的延迟需要是否满足了,无论是使用throughput垃圾回收器或者并发垃圾回收器。如果没有能够满足应用的需要，那么回头看看需求是否合理或者修改应用程序。如果满足了应用的需求，那么我们就进入下一步——优化吞吐量。