JVM 和 GC 调整 - 没有 Full GC 的理论

Question

我有两种类型的对象的大规模应用程序：长寿命（缓存）和短寿命（请求-过程-响应）。 理论上，用这种类型的应用，我觉得可以配置 Young vs Old 空间，所以 Old 空间消耗是恒定的，导致没有 Full GC。

我已经更改了 newSize-maxNewSize 参数，但是，旧堆继续上升，直到 Full GC。 每次 Full GC 后，消耗下降到 20%（缓存占 20%）。 出于某种原因，我的对象进入了旧空间。 我有两个怀疑为什么要搬到旧空间：

• 根据这篇文章： http://chaoticjava.com/posts/gc-tips-and-memory-leaks/如果您分配了大对象，那些 go 直接分配给旧空间。 这是真的吗，如果是，是否有 JVM 选项参数可以设置年轻空间的 object 大小阈值？

• 如果我正确理解了该过程，则对象会在 To-From 生存部分之间切换，然后再移至旧部分。 是否有参数可以设置在移动到旧空间之前要在 To 和 From 之间进行多少次切换？

还有其他提示吗？

谢谢，阿马尔

Answer 1

听起来您的幸存者空间确实不够大。 您需要使它们足够大，以至于不需要收集任何对象。 object 只进出幸存者空间一次。

如果您正在分配大对象，您可以使用 Object 池来避免对它们进行 GC。 您是否考虑过将 object 池也用于您的请求/处理/响应数据？ 例如，一个简单的方法是使用 ThreadLocal。

您是否尝试过 G1 收集器，该收集器旨在逐步收集您的所有 memory 并减少完整 GC 的大命中。

Answer 2

你确定老年代的增长只是没有缓存对象吗？ 除非您的缓存是固定的并且永远不会更改，否则您将不断地添加它。 由于已经进入老年代的对象从该缓存中过期，它们将留在 memory 直到下一次完整的 GC。

并发标记扫描收集器完全消除了完整 GC 的长时间停顿，我的运气要好得多。 这需要一些调整，并且可能因应用程序而异。 以下是我们用来运行 24GB 64 位 JVM 的方法，其 GC 暂停时间为亚秒级，同时通过大型缓存每秒处理 100 多个页面请求：

-Xms24g -Xmx24g -XX:+UseCompressedOops -XX:NewRatio=4 -XX:SurvivorRatio=8    
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+DisableExplicitGC  
-XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled  
-XX:+CMSScavengeBeforeRemark -XX:CMSInitiatingOccupancyFraction=68

Answer 3

是否有参数可以设置在移动到旧空间之前要在 To 和 From 之间进行多少次切换？

是的， -XX:MaxTenuringThreshold

此开关确定对象在提升到老一代之前在“From”和“To”Survivor 空间之间跳跃的次数。 Java 6 的最大值为 15，早期 JDK 的最大值为 31。 并行收集器的默认值为 15，CMS 收集器的默认值为 4 。

来自 Sun JVM GC 文档，

使用 -XX:MaxTenuringThreshold=0 将在年轻代收集中幸存的 object 立即移动到终身代。

正如你想做的相反，如果你没有设置这个值，它将是默认值，这足以决定 object 是否需要将 go 转换为Old - 正如@Peter所说，幸存者是大到足以容纳这些物体。

您的 SurvivorRatio 设置为多少？ 你的总堆是多少？

Answer 4

Object 生命周期特征在这里起着至关重要的作用。重要的调整旋钮是幸存者空间的大小、任期阈值和年轻代的大小。 从战略上讲，我们希望对象在年轻一代中死亡，因此如果次要 collections 之间有足够的差距，很多 object 将在年轻一代中死亡。 此外，我们可以配置任期阈值，以便对象在幸存者空间中保留所需数量的 collections。

由于我们在幸存者空间中保留了大量活动对象，并不断将它们从一个空间复制到另一个空间以进行多次次要 GC，因此增加了次要 GC 的成本。

保持较大的年轻代自然会增加连续次要 collections 之间的差距，并为对象提供更多死亡时间。

可以通过试验这些变量来达到适当的平衡，以减少 object 对老一代的提升，并考虑可接受的年轻一代暂停