我正在升级生产硬件，而且我们在新套件上看到了比旧版更多的年轻人GC。
两台计算机上正在运行相同的程序（相同的二进制文件）。一个明显的区别（我希望这对JVM没有任何影响）是我们已经升级了RHEL5 - ＆gt; RHEL6。
我们的JVM（Java 64位Hotspot 1.6，两者上都是java -version）运行时使用相同的命令行GC选项：
-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseParallelGC -XX:+UseCompressedOops
此外：
-Xmx1024M -Xms1024M -XX:NewSize=512M -XX:SurvivorRatio=2
机器之间的区别在于新盒子的内存大约是RAM的两倍（32gb - 虽然最大堆没有变化）和一些核心（24对16）。
应用程序本身连接到多个外部进程并执行大量网络操作 - 因此可能表示某些回归，错误配置或不兼容（这就是我们测试的原因......）。我想知道的是：
年轻一代GC的增加水平可能是在更多核心上运行的自然和预期结果，还是我应该关注这一发展？
我们确认了JConsole中的GC数量，但这与执行相同：
grep "PSYoungGen" ./log | wc -l
（注意-XX:+PrintGC -XX:+PrintGCDetails）
两个盒子上的完整GC看起来大致相同。
请注意，这是整个应用程序启动过程中GC的数量 - 因此它不会执行“更多工作”。这是同样的工作，有更多的GC运行。
我想知道，例如，-XX:+UseParallelGC是否会在日志中导致更多条目，因为正在使用更多的线程（将年轻的集合切成小块，意味着更多，更小的集合 - 而不是担心）。
答案 0 :(得分：1)
令人费解的问题......
简短回答
不，GC频率只是您创建速率的函数。除非您的应用程序利用这种新硬件，否则GC频率应该相同。
答案很长
我不认为它与操作系统升级有关，也不认为总RAM的增加与它有关。
它不能来自指针大小的增加，因为最大堆大小是1GB。因此，即使您使用的是64位JVM，JVM也已经使用了32位指针。
您的应用程序在启动期间是否使用了所有内核？
它可以解释YoungGC速率的增加：如果您的应用程序使用8个以上的线程，则意味着它将在相同的时间内执行更多的工作。您应该观察到分配率的增加（参见GC日志）。
您还应该注意到Young GC持续时间的下降，因为PSScavenge使用更多线程。这是对的吗？
根据this page，ParallelGCThreads = (ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8)。您使用13个线程进行YGC循环，现在使用18个。
答案 1 :(得分：-3)
它取决于你的os体系结构（x64或x86）和x86 jvm上升到4Gb，x64上升到2Gb（RAM ammount）。