如果堆增长到其最大大小而吞吐量目标不是 如果满足，则最大堆大小对于吞吐量目标而言太小。 将最大堆大小设置为接近总计的值 平台上的物理内存，但不会导致交换 应用程序。再次执行该应用程序。如果吞吐量目标 仍然没有满足，那么申请时间的目标太高了 了解平台上的可用内存。
[Edit_1：我在下面添加了完整的段落，这使我在阅读the8472's answer后认为有所不同。
影响垃圾收集性能的最重要因素是 总可用内存。因为收藏发生在世代 填满，吞吐量与内存量成反比 可用。
在我看来，这两个句子都是矛盾的。
听起来我的第一句话是建议更大的堆大小使得实现更高的吞吐量（应用程序吞吐量）成为可能或更容易。我看到这个的方式是应用程序有一个巨大的playground \ heap来进行各种分配而不会触发GC，所以应用程序执行的时间比自动执行的时间要长，因为较少的GC会冻结应用程序
但第二个引用明确指出，如果内存量增加，吞吐量会降低。这对我来说听起来完全错了！或者第二个引用是指GC的吞吐量？这就是垃圾收集器完成的工作量，这对我来说非常有意义。但是，吞吐量在阅读引用的教程时更像是一个术语，它意味着应用程序吞吐量。 [Edit_1：我猜引用的是指GC的吞吐量而不是应用程序的数据]
我在这里弄错了什么？
答案 0 :(得分：2)
当您相对于应用程序实际需要的数据量（实时集大小）增加最大堆大小时，它会增加吞吐量，因为并行GC必须运行频率较低，因此可以更有效地工作。
另一方面，如果实时设置大小增加但最大堆大小保持不变，则GC必须更频繁地运行以实现越来越少的工作量，从而降低吞吐量。
仅考虑未来老一代的简化计算：
如果你的程序以1GB / s的速度使用对象，那么收集器以4GB / s的速度移动对象，然后你给它100GB的RAM然后你的实时设置大小为2GB然后需要98s来填充堆和0.5收集。申请吞吐量= 99.4％
如果你的程序以1GB / s的速度使用对象，那么收集器以4GB / s的速度移动对象，然后你给它10GB的RAM然后你有一个2GB的实时集大小然后需要8s来填充堆和0.5收集。申请吞吐量= 94.1％
如果你的程序以1GB / s的速度使用对象，那么收集器以4GB / s的速度移动对象，然后你给它100GB的RAM然后你有一个80GB的实时设置大小然后需要20s来填满堆和20s去收集。申请吞吐量= 50％
答案 1 :(得分：1)
您没有弄错，该指南是矛盾的，因为您引用的第二段是错误的，或者是极具误导性的（在没有明确说明的情况下将吞吐量定义为不同的内容）。
指南的其余部分非常好。
该错误也在Java 11版本中： Java SE11，HotSpot Virtual Machine Garbage Collection Tuning Guide, chapter 4, Factors Affecting Garbage Collection Performance：
第4章，“影响垃圾收集性能的因素”：
总堆 影响垃圾收集性能的最重要因素是 总可用内存。因为收集发生在世代之间 填满后，吞吐量与内存量成反比 可用。
该指南的其余部分的确将其用作应用程序/系统吞吐量，并且吞吐量通常是三个GC调整目标之一，因此我认为这是一个错误。
据我所知，通常应该相反：
吞吐量通常与可用内存量成正比。
关于您的主要问题。我认为在某些特定情况下，如果堆大小增加，则应用程序吞吐量会降低。我可以想到很多情况下添加内存不能解决调优问题，但是我无法想到添加内存实际上会使吞吐量变差。
Java Performance by Charlie Hunt and Binu John在第7章“调优JVM”中非常清楚地介绍了吞吐量，内存和等待时间之间的定义和关系。逐步”》第256-257页：
吞吐量 吞吐量是可以执行的工作量的度量 每单位时间。吞吐量要求忽略延迟或 响应能力。通常，增加吞吐量是以牺牲以下成本为代价的 延迟增加和/或内存占用增加。
性能吞吐量要求的一个示例是“应用程序 应该每秒执行2500个事务。”
延迟和响应能力 延迟或响应度是衡量两次之间的经过时间的量度 当应用程序收到激励以执行某些工作并且该工作 完成了。延迟或响应性要求被忽略 吞吐量。通常情况下，响应速度加快或延迟降低 以降低吞吐量和/或增加内存为代价 足迹。
延迟或响应能力要求的一个示例是“ 申请应在60天内完成交易请求 毫秒。”
内存占用量 内存占用量是运行所需的内存量的量度 以某种吞吐量，某种程度的延迟， 和/或某种程度的可用性和可管理性。内存占用 通常表示为运行所需的Java堆数量 应用程序和/或运行程序所需的内存总量 应用。通常，通过增加内存占用量来增加 Java堆大小可以提高吞吐量或减少延迟，或两者兼有。 随着可供应用程序使用的内存减少， 通常会牺牲吞吐量或延迟。