oracle java官方文档中处理器的吞吐量是多少？答案

【问题标题】：What is the figure which is throughput with processor means in oracle java official documentoracle java官方文档中处理器的吞吐量是多少？
【发布时间】：2022-02-18 23:54:39
【问题描述】：

“Java 平台，标准版 HotSpot 虚拟机垃圾收集调优指南”，解释 its figure 1-1 如下所示

红线是一个应用程序在单处理器系统上仅花费 1% 的时间进行垃圾收集。这意味着在具有 32 个处理器的系统上，吞吐量损失超过 20%。

我不明白这些数字的真正含义。
是不是说，在gc时间固定的情况下，GC会因为暂停而影响CPU的吞吐量？

【问题讨论】：

您有相关文档部分的链接吗？
是不是说，在gc时间固定的情况下，GC因为暂停而影响CPU的吞吐量？是的。随着处理器数量的增加，1% 的 GC 时间相当于 32 个 CPU 上 30% 的时钟时间。而 30% 的 GC 导致几乎 100% 的时间花在 GC 上。基本上，这是对阿姆达尔定律的重新陈述。
基本上我在问，因为您的问题中没有足够的信息来确定答案。我认为引用是指旧的 stop-the-world mark-and-sweep GC，但我无法确定。
@markspace 感谢您的帮助。我在docs.oracle.com/javase/10/gctuning/…看到它
@Elliott Frisch 感谢您的评论。但我还是不明白，这是否意味着处理器越少吞吐量越好？我是这么想的，因为当我们只看到红线时，它表明处理器小于 5 时比处理器编号为 32 时的吞吐量更好。

标签： java garbage-collection

【解决方案1】：

以下是您找到此图表的文档中的说明文字：

图 1-1 中的图表模拟了一个理想的系统，该系统除了垃圾收集之外完全可扩展。红线是一个应用程序在单处理器系统上仅花费 1% 的时间进行垃圾收集。这意味着在具有 32 个处理器的系统上，吞吐量损失超过 20%。洋红色线表明，对于 10% 的垃圾收集时间的应用程序（在单处理器应用程序中的垃圾收集时间不被认为是惊人的时间），当扩展到 32 个处理器时，超过 75% 的吞吐量会丢失。

图表下方的链接显示：

该图模拟了一个理想的系统，该系统除了垃圾收集 (GC) 之外完全可扩展。它绘制了处理器数量（x 轴）与吞吐量（y 轴）的关系。它包含 6 条标绘线，分别标记为 1% GC、2% GC、3% GC、10% GC、20% GC 和 30% GC。每条线表示在单处理器系统上与在多处理器系统上花费指定百分比的时间用于垃圾收集的应用程序的吞吐量变化。该图在其前面的文本中进行了描述。

所以……

这是一个模型，而不是实际测量性能的图表。
模型是理想化的。它假定应用程序是完全可扩展的（GC 除外）。
它说明了当您不使垃圾收集可伸缩时会发生什么；例如如果只有一个 GC 线程并且它不与应用程序线程并行运行。
1% GC、2% GC 等行表示单处理器系统上不同的模型化 GC 负载。因此，1% 的线表示应用程序在单处理器系统上运行的情况，其中应用程序线程生成的 GC 负载可以使用 1% 的可用 CPU 来收集。
吞吐量表示繁忙的应用程序正在完成的有用（应用程序）工作；即*没有被垃圾收集占用或等待 GC 完成的时间（GC 开销）。
吞吐量以具有给定处理器数量的系统上可用 CPU 时间的百分比来衡量。

因此，例如，在 30% 的 GC 级别，32 核系统的吞吐量将大约是硬件理论吞吐量的 1/10。它将浪费大约 9/10 的可用 CPU 时间等待垃圾收集完成！

【讨论】：

【解决方案2】：

重要的是Amdahl's law，它指出“通过优化系统的单个部分获得的整体性能改进受到实际使用改进部分的时间分数的限制”。

您可以计算图表。

【讨论】：