一般来说，cms垃圾收集器（或任何其他并发垃圾收集器）的cpu利用率高于吞吐量垃圾收集器，这在第108页的《java性能最终指南》一书中提到：
当使用cms或g1收集器时，应用程序通常会经历较少（并且更短）的暂停。权衡的结果是，应用程序总体上将使用更多的cpu。
在第109页：
使用并发收集器避免长时间暂停的好处是以额外的cpu使用为代价的。
但在第115页的书中有一个例子，cms collector的cpu利用率较低（包括平均值和pick）：
吞吐量收集器在运行时（默认情况下）将消耗机器上100%的可用cpu，因此在测试期间cpu使用情况的更准确表示如图5-2所示。大多数情况下，只有应用程序线程在运行，占用了总cpu的25%。当gc启动时，100%的cpu被消耗。因此，实际的cpu使用量类似于图中的锯齿形模式，即使测试期间的平均值报告为直线虚线的值。

当后台线程与应用程序线程同时运行时，并发收集器中的效果不同。在这种情况下，cpu的图形可能如图5-3所示。

应用程序线程首先使用总cpu的25%。最终它为cms后台线程创建了足够的垃圾；该线程还消耗了整个cpu，使总数达到50%。当cms线程完成时，cpu使用率下降到25%，以此类推。请注意，没有100%的cpu峰值周期，这有点简单：在cms年轻一代收集期间，会有非常短的峰值达到100%的cpu使用率，但是这些峰值足够短，我们可以在本次讨论中忽略它们。
为什么在这种情况下cms垃圾收集器的cpu使用率会低于吞吐量垃圾收集器？