如果堆大小增加，应用程序吞吐量会降低吗？

Question

引用此页

如果堆增长到最大大小，并且无法满足吞吐量目标，则最大堆大小对于吞吐量目标而言太小。 将最大堆大小设置为接近平台上总物理内存但不会导致应用程序交换的值。 再次执行该应用程序。 如果仍然没有达到吞吐量目标，那么对于平台上的可用内存来说，应用程序时间目标太高了。

从这个页面

[Edit_1：我在下面添加了完整的段落，这使我在阅读the8472的答案后有不同的看法 ]

影响垃圾收集性能的最重要因素是总可用内存。 由于收集是在世代填满时发生的，因此吞吐量与可用内存量成反比。

在我看来，这两个句子是矛盾的。

在我看来，第一句话表明，更大的堆大小可能或容易实现更高的吞吐量（应用程序吞吐量）。 我看到的方式是，应用程序具有巨大的操场\\堆，可以在不触发GC的情况下进行各种分配，因此，如果堆很低，则应用程序的自由执行时间要长得多，因为更少的GC将冻结应用程序。

但是第二个引号明确指出，如果内存量增加，则吞吐量会降低。 这听起来对我完全不对！ 还是第二个引用是指GC吞吐量？ 那就是垃圾收集器完成的工作量，那对我而言将是非常合理的。 但是在阅读参考教程时， 吞吐量更像是一个行话，它意味着应用程序吞吐量。 [Edit_1：我想报价是指GC的吞吐量，而不是应用程序的吞吐量]

我在这里弄错了什么？

Answer 1

当您增加最大堆大小（相对于应用程序实际需要的数据量）（实时设置大小）时，它会增加吞吐量，因为Parallel GC的运行频率较低，因此可以更高效地工作。

另一方面，如果活动集大小增加但最大堆大小保持恒定，则GC必须更频繁地运行以实现越来越少的工作量，从而降低吞吐量。

简化计算仅考虑了未来的一代：

如果您的程序以1GB / s的速度占用对象，收集器以4GB / s的速度移动对象，则给它提供100GB的RAM，然后您拥有2GB的实时设置大小，那么将需要98秒来填充堆，而需要0.5s来收集。 应用程序吞吐量= 99.4％

如果程序以1GB / s的速度占用对象，收集器以4GB / s的速度移动对象，则给它10GB的RAM，然后您拥有2GB的实时设置大小，那么将需要8s来填充堆，而0.5s来收集。 应用程序吞吐量= 94.1％

如果您的程序以1GB / s的速度租用对象，收集器以4GB / s的速度移动对象，则给它提供100GB的RAM，然后您拥有80GB的实时设置大小，那么将需要20s来填充堆，而20s来收集。 应用程序吞吐量= 50％

Answer 2

您没有弄错，该指南是矛盾的，因为您引用的第二段是错误的，或者是极具误导性的（将吞吐量定义为不同的东西，而无需弄清楚这一点）。

但是，该指南的其余部分非常好。

Java 11版本中也存在该错误：Java SE11， HotSpot虚拟机垃圾收集优化指南，第4章，影响垃圾收集性能的因素 ：

第4章，“影响垃圾收集性能的因素”：

总堆影响垃圾收集性能的最重要因素是总可用内存。 由于收集是在世代填满时发生的，因此吞吐量与可用内存量成反比。

本指南的其余部分确实将术语称为应用程序/系统吞吐量 ，并且吞吐量通常是三个GC调整目标之一，因此我认为这是一个错误。

据我了解，这通常是相反的：

吞吐量通常与可用内存量成正比。

关于您的主要问题。 我认为在某些特定情况下，如果堆大小增加，则应用程序吞吐量会降低。 我可以想到很多情况下添加内存不能解决调优问题，但是我无法想到添加内存实际上会使吞吐量变差的任何情况。

Charlie Hunt和Binu John撰写的Java Performance在第7章“逐步调试JVM”（第256-257页）中非常清楚地介绍了吞吐量 ， 内存和延迟之间的定义和关系：

吞吐量吞吐量是对每单位时间可以执行的工作量的度量。 吞吐量要求忽略了延迟或响应能力。 通常，增加吞吐量是以增加等待时间和/或增加内存占用为代价的。

性能吞吐量要求的一个示例是“应用程序应每秒执行2500个事务”。

延迟和响应性延迟或响应性是对应用程序收到激励以完成某些工作到完成工作之间经过的时间的度量。 延迟或响应性要求会忽略吞吐量。 通常，增加响应速度或降低延迟会以降低吞吐量和/或增加内存占用为代价。

延迟或响应性要求的一个示例是“应用程序应在60毫秒内执行交易请求以完成。”

内存占用空间内存占用空间是衡量以某个级别的吞吐量，某个级别的延迟和/或某个级别的可用性和可管理性运行应用程序所需的内存量的度量。 内存占用量通常表示为运行应用程序所需的Java堆数量和/或运行应用程序所需的内存总量。 通常，通过增加Java堆大小来增加内存占用量可以提高吞吐量或减少延迟，或两者兼而有之。 随着可供应用程序使用的内存减少，通常会牺牲吞吐量或等待时间。