在生产中运行的当前基于 BPM 的应用程序(部署在 JBOSS AS 4.2.3 中)中，注意到一些性能问题，这是因为峰值负载期间运行的 GC 挂起周期较长。通过对相同内容进行更多分析，我发现正在运行的 JVM 实例的 jstat 实用程序有以下输出。
/usr/jdk1.6.0-x64/bin/jstat -gccapacity 5583 NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC PGCMN PGCMX PGC PC YGC FGC 838848.0 1677696.0 1677696.0 167744.0 167744.0 1342208.0 3355456.0 6710912.0 6710912.0 6710912.0 21248.0 524288.0 480084。 0 480084.0 8448 268 /usr/jdk1.6.0-x64/bin/jstat -gcutil 5583 1s S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 46.33 23.11 81.23 60.38 8451 1386.335 268 159.553 1545.887 0.00 46.33 27.99 81.23 60.38 8451 1386.335 268 159.553 1545.887在第一个命令中，(使用选项 -gccapacity)我观察到，NGC = NGCMX 和 OGC = OGCMX。也就是说，当前旧发电容量达到最大旧发电容量，当前新发电容量达到最大新发电容量。
我想了解，这可能是频繁 GC 周期和一些大执行的原因(有时需要超过 25-30 秒)吗？
对于当前分辨率，我们已将最大 JVM 堆内存从 8 GB 增加到 9 GB。但是，我们需要了解可能的原因，以便我们可以向开发团队提出同样的问题来优化应用程序。
最佳答案
如果您想了解内存使用的原因，我建议您使用内存分析器。一种选择是使用 VisualVM，但是像 YourKit 这样的商业分析器可以更好地处理更大的内存。
从 8 GB 增加到 9 GB 不太可能产生太大影响。如果您有内存，请尝试 16 GB 或 30 GB，看看是否超出您的需要，然后减少内存。
如果您无法在生产中分析您的应用程序，并且测试没有重现相同的行为，您可以使用 jmap -histo 来了解最大的内存消耗者。有时这会给您提供线索。
关于java - 调查垃圾收集周期原因，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21465868/