从this page引用
如果堆增长到最大大小，并且吞吐量目标未达到
达到最大堆大小对于吞吐量目标而言太小。
将最大堆大小设置为接近总大小的值
平台上的物理内存，但不会导致交换
应用程序。再次执行该应用程序。如果吞吐量目标
仍然没有达到，那么申请时间目标太高了
平台上的可用内存。
从this page
[Edit_1：我在下面添加了完整的段落，这使我在阅读the8472's answer后有不同的看法]
影响垃圾收集性能的最重要因素是
总可用内存。因为收集发生在世代之间
填满后，吞吐量与内存量成反比
可用。
在我看来，这两个句子是矛盾的。
在我看来，第一个引号是暗示较大的堆大小可以实现或容易实现更高的吞吐量（应用程序吞吐量）。我看到的方式是，应用程序具有巨大的操场\堆，可以在不触发GC的情况下进行各种分配，因此，如果堆很低，则应用程序的自由执行时间要长得多，因为更少的GC将冻结应用程序。
但是第二个引号明确指出，如果内存量增加，则吞吐量会降低。这听起来对我完全不对！还是第二个引用是指GC吞吐量？那就是垃圾收集器完成的工作量，那对我而言将是非常合理的。但是在阅读参考教程时，吞吐量更像是一个行话，它意味着应用程序吞吐量。
[Edit_1：我想报价是指GC的吞吐量，而不是应用程序的吞吐量]
我在这里错了什么？
最佳答案
随着相对于应用程序实际需要的数据量（实时设置的大小）增加最大堆大小，这将增加吞吐量，因为Parallel GC的运行频率较低，因此可以更高效地工作。
另一方面，如果活动集大小增加，但最大堆大小保持不变，则GC必须更频繁地运行以实现越来越少的工作量，从而降低吞吐量。
仅考虑未来一代的简化计算：
如果您的程序以1GB / s的速度占用对象，收集器以4GB / s的速度移动对象，则给它提供100GB的RAM，然后您拥有2GB的实时设置大小，那么将需要98s来填充堆，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％
关于java - 如果堆大小增加，应用程序吞吐量会降低吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/48281963/