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

Question

引用自this page

If the heap grows to its maximum size and the throughput goal is not being met, the maximum heap size is too small for the throughput goal. Set the maximum heap size to a value that is close to the total physical memory on the platform but which does not cause swapping of the application. Execute the application again. If the throughput goal is still not met, then the goal for the application time is too high for the available memory on the platform.

来自 this page

[Edit_1:我添加了下面的完整段落，这让我在阅读 the8472's answer 后有了不同的想法]

The most important factor affecting garbage collection performance is total available memory. Because collections occur when generations fill up, throughput is inversely proportional to the amount of memory available.

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

在我看来，第一句话表明较大的堆大小可以或更容易地实现更高的吞吐量(应用程序吞吐量)。我的看法是，应用程序有一个巨大的 Playground \堆来执行各种分配而不触发 GC，因此应用程序自由执行的时间比堆较低时要长得多，因为较少的 GC 会卡住应用程序.

但是第二个引用明确指出，如果内存量增加，吞吐量就会降低。这对我来说听起来完全错误!或者第二个引用可能指的是 GC 吞吐量？这就是垃圾收集器完成的工作量，这对我来说非常有意义。但是，在阅读引用教程时，吞吐量更像是一个行话，它意味着应用程序吞吐量。[Edit_1:我猜引用是指 GC 的吞吐量，而不是应用程序的]

我在这里做错了什么？

Answer 1

当您相对于应用程序实际需要的数据量(实时集大小)增加最大堆大小时，吞吐量就会增加，因为并行 GC 的运行频率会降低，从而可以更高效地工作。

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

仅考虑前面的老一代的简化计算:

如果你的程序以 1GB/s 的速度占用对象，收集器以 4GB/s 的速度移动对象，那么你给它 100GB 的 RAM，并且你的实时设置大小为 2GB，那么填满堆需要 98 秒，并且需要 0.5 秒来收集。应用程序吞吐量 = 99.4%

如果你的程序以 1GB/s 的速度占用对象，收集器以 4GB/s 的速度移动对象，那么你给它 10GB 的 RAM，并且你的实时设置大小为 2GB，那么填满堆需要 8 秒，需要 0.5 秒来收集。应用程序吞吐量 = 94.1%

如果你的程序以 1GB/s 的速度占用对象，收集器以 4GB/s 的速度移动对象，那么你给它 100GB 的 RAM，并且你的实时设置大小为 80GB，那么需要 20 秒才能填满堆，然后需要 20 秒去收集。应用程序吞吐量 = 50%