CMS垃圾收集器不使用整个CPU的原因

Question

在“Java性能最终指南”一书中，比较了吞吐量垃圾收集器和CMS垃圾收集器的CPU利用率，如下所示：

吞吐量收集器(默认情况下)运行时将消耗机器上可用CPU的100%，因此在此测试期间更准确地表示CPU使用情况，如图5-2所示。大多数情况下，只有应用程序线程在运行，消耗了整个CPU的25%。当GC启动时，将消耗100%的CPU。因此，虽然测试期间的平均值被报告为直线虚线的值，但实际CPU的使用情况类似于图形中的锯齿形。

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

应用程序线程从使用CPU总数的25%开始。最终，它已经为CMS后台线程创建了足够的垃圾来启动；该线程还消耗了整个CPU，使总数达到50%。当CMS线程完成时，CPU使用率下降到25%，依此类推。请注意，没有100%的峰值CPU周期，这有点简化:在CMS年轻一代集合期间，CPU使用率将有很短的峰值到100%，但是这些周期足够短，我们可以在本文中忽略它们。

我知道当吞吐量垃圾收集器运行时，它会停止所有应用程序线程，而CMS垃圾收集器与其他应用程序线程同时运行，但我不明白为什么当吞吐量收集器启动时，它可以使用整个CPU周期并将CPU利用率提高到100%，但是当CMS收集器启动时，CPU未被利用的比例却上升了50%？有什么可以阻止CMS收集器使用所有可用的CPU资源吗？

Answer 1

由于CMS收集器同时执行一些工作，所以设计它的目的是不使用所有可用的系统资源，而是更像后台任务。这在更大程度上适用于G1和ZGC。

由于并行收集器是同步的，所以它被设计为使用所有可用的系统资源来尽快完成工作。

Answer 2

我喜欢这个与现实几乎没有任何联系的虚构的图表；然后，CMS在java-14中被废弃和删除，只是FYI。我也不是GC专家，但我喜欢摆弄不同的代码实现(特别是在Shenandoah代码库中)，作为免责声明。

想想看:当你停止世界，把每一个线程带到一个地方去做GC时，你的首要任务就是快速、非常快地完成这个任务。因为找出什么是垃圾，并将东西移动到清除区域是CPU绑定的任务，因此您需要尽可能多的CPU和尽可能多的合理线程来执行这一任务。因此，CMS和其他收集器一样，在他们的STW暂停将使CPU达到最大值，从而工作完成得更快。由于吞吐量收集器根本没有任何并发暂停，这些峰值可能更可见。相反，CMS中的某些阶段是concurrent，因此在图形中可能看不到太多的CPU利用率。

值得注意的是，某些垃圾收集器可以故意使应用程序运行得更慢。它们可以降低"mutator“(应用程序)线程的优先级，并提高GC实现本身的优先级。Shenandoah将此称为“步调”，当分配速率太高而GC线程无法处理时，它就会这样做。

但我要重复一遍，这是一个虚构的图表和正确的理解和正确的结论CPU利用率到目前为止，不是微不足道的。