java - JVM 堆 - 为什么 S0/S1 的大小会随着时间的推移而减小？

Question

我们有一个 java 服务器应用程序正在生成大量临时数据，因此在 GC 中消耗了大量时间。我们正在尝试微调其 JVM 设置以获得最佳性能。目前我们的 jvm 设置是:java -server -Xmx45700m -Xms34275m -XX:InitialTenuringThreshold=15 -XX:MaxTenuringThreshold=15 -XX:NewSize=32132m -XX:SurvivorRatio=4

我们设置了更高的幸存者比率，以防止这些临时数据被移动到老年代区域。

我们看到的奇怪行为是，随着时间的推移，S0/S1 大小从配置的 5G 大小减少到小于 1G。

这是从应用程序生命周期的开始:堆

 PSYoungGen      total 27419648K, used 9887259K [0x00007ff819f80000, 0x00007ffff2380000, 0x00007ffff2380000)
  eden space 21936128K, 44% used [0x00007ff819f80000,0x00007ffa6773e488,0x00007ffd54d80000)
  from space 5483520K, 4% used [0x00007ffea3880000,0x00007ffeb18489f0,0x00007ffff2380000)
  to   space 5483520K, 0% used [0x00007ffd54d80000,0x00007ffd54d80000,0x00007ffea3880000)
 ParOldGen       total 2194432K, used 104K [0x00007ff4c9f80000, 0x00007ff54fe80000, 0x00007ff819f80000)
  object space 2194432K, 0% used [0x00007ff4c9f80000,0x00007ff4c9f9a018,0x00007ff54fe80000)
 PSPermGen       total 37376K, used 37233K [0x00007ff4c4d80000, 0x00007ff4c7200000, 0x00007ff4c9f80000)
  object space 37376K, 99% used [0x00007ff4c4d80000,0x00007ff4c71dc418,0x00007ff4c7200000)

And this is after some time:
Heap
 PSYoungGen      total 32397312K, used 4399893K [0x00007ff819f80000, 0x00007ffff2380000, 0x00007ffff2380000)
  eden space 31891456K, 12% used [0x00007ff819f80000,0x00007ff907a4cbc0,0x00007fffb4780000)
  from space 505856K, 99% used [0x00007fffb4780000,0x00007fffd35788b8,0x00007fffd3580000)
  to   space 505856K, 0% used [0x00007fffd3580000,0x00007fffd3580000,0x00007ffff2380000)
 ParOldGen       total 2194432K, used 774462K [0x00007ff4c9f80000, 0x00007ff54fe80000, 0x00007ff819f80000)
  object space 2194432K, 35% used [0x00007ff4c9f80000,0x00007ff4f93cfa40,0x00007ff54fe80000)
 PSPermGen       total 45568K, used 45222K [0x00007ff4c4d80000, 0x00007ff4c7a00000, 0x00007ff4c9f80000)
  object space 45568K, 99% used [0x00007ff4c4d80000,0x00007ff4c79a9900,0x00007ff4c7a00000)

为什么从5G降到0.5G？

Answer 1

因为您使用的是并行收集器，它以吞吐量为目标。

在幸存者空间之间来回复制 5GB 的对象多次很可能是浪费了 CPU 周期，如果只有一小部分对象在每个保留时间间隔内死亡。因此 GC 缩小幸存者空间并尽快将它们复制到老年代以避免重复成本，希望稀有的老年代 GC 在花费的 CPU 周期方面相对于收集的垃圾数量而言效率更高，即提高吞吐量。

此时您的老一代只有 2GB 的对象。与 GC 多次收集值(value) 5GB 的对象相比，偶尔收集一次要便宜得多。

庞大的年轻一代总体上看起来很奇怪。您是否实际进行了测量并确认这会有所改善？