垃圾收集器将尝试适当调整堆的大小，但将避免使用同一机器上多半的可用物理内存。还需要花费一 段时间来增加堆的大小以便获得最优大小，如果应用程序占用下降，则可以缩小堆。堆大小的这些上下浮 动可能会降低应用程序的速度，但如果同一系统上运行的其他程序不需要物理内存，则没有必要这样。如 果正确理解了应用程序的内存要求，则固定堆大小便是一个简单的性能优化问题。

对于堆来说，没有一个理想的堆大小。通常，堆大小越大应用程序执行得越好，因此调整堆大小涉及 权衡应用程序的要求以及物理内存的其他需求。 比较合理的试探是 堆大小应该至少为活动数据的数量的 两倍。如果这不可能实现或者想使堆更大，则 gencon 策略可能是最佳选择，因为在堆大小受限制的情况 下，该策略一般胜过 optthruput 策略。如果这些都有可能，则不应该调整堆大小以便机器需要使用虚拟 内存来容纳它。使用虚拟内存会大大降低性能。

固定堆大小的优势

图 18 显示了当 图 7 中的相同工作负载运行在堆大小固定为 500MB 的 JVM 中的暂停时间，命令行 选项为 -Xms500m -Xmx500m。 仅仅根据暂停时间判断，固定堆大小似乎使问题变得更糟。每个策略的平 均暂停时间都增加了，但花费在 GC 上的时间比例并没有改变。因此实际上总的暂停时间（报告视图中表 的第四列）大大下降了。总的暂停时间和平均暂停时间似乎不一致，因为在小堆中收集完成得非常快。当 堆的大小可变时，尽管堆很小，但 JVM 执行很多收集都非常迅速，这些都导致平均暂停时间较短。在这 种情况下，最终的性能度量是 JVM 完成工作所花费的时间（线条的长度）；对于 gencon 策略，固定堆 会提高 13%，对于 optavgpause 策略则会提高 15%，而对于 optthruput 策略则会提高 30%。

图 18. 在固定堆中运行的应用程序的暂停时间

当然，本示例针对的是 Java 程序，它执行时间超过 30 秒，其中 JVM 将初始时间的大部分花费在查 找最佳堆大小上面。固定堆大小通常不会对长时间运行的程序有明显的改善。如果没有正确理解工作负载 ，则固定堆大小是非常不明智的，因为这样可能会迫使 JVM 在太小的堆中运行。可以使用详细 GC 输出 来评估工作负载的稳定性以及 JVM 需要高于允许内存的风险。

IBM的Java诊断，第2部分(13)

案例研究：通过详细 GC 日志评估应用程序吞吐量

您可以调整 GC 以优化应用程序的性能。但是如何确定应用程序执行得如何呢？基准具有明确的性能 度量，但是调整垃圾收集器来优化基准，然后认为相同的配置将会为不同的应用程序提供最佳结果，这是 非常不明智的。所有应用程序都是不相同的，并且垃圾收集器没有最佳配置。（如果有的话，垃圾收集器 将提供该配置，那么调整就没有必要了。） 与基准不同的是，并非所有应用程序都提供显示其执行好坏 程度的报告。

在这些情况下，详细 GC 日志本身就可以提供有关应用程序执行情况的最佳提示。尽管详细 GC 日志 是评估应用程序性能的好起点，而报告的暂停时间一定不是 正确的起点。正如上文所示的固定堆示例， 应用程序可能有时的运行速度比调整前快，但仍然由未改变的 GC 开销甚至更长的平均暂停时间表示。花 费大量时间执行 GC 的应用程序的确看上去性能降低了，但由于对象的排列方式，在 GC 上花费更多时间 有时可能会使应用程序执行得更好。

GC 如何加快应用程序的速度？

好的

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!