在生产中运行的当前基于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秒）的原因吗？
对于当前的解决方案，我们将Max JVM堆内存从8 GB增加到9 GB。但是，我们需要了解可能的原因，以便我们可以向开发人员团队提出相同的优化应用程序。
答案 0 :(得分：2)
如果您想了解内存使用的原因，我建议您使用内存分析器。一种选择是使用VisualVM，但像YourKit这样的商业分析器可以更好地处理更大的内存。
从8 GB增加到9 GB不太可能产生太大影响。如果你有内存尝试16 GB或30 GB，看看这是否超过你需要，然后减少它。
如果您无法在生产中分析您的应用程序并且测试不会重现相同的行为，您可以使用jmap -histo来了解最大的内存消费者。有时这会给你一个线索。
答案 1 :(得分：0)
如果您关注的是 GC ，也许您可以尝试使用其他 GC算法，甚至可以尝试使用其他 GC算法。 你描述的场景看起来真的像GC算法不能满足你的需求。
算法并行收集器（您可以使用 -XX：+ UseParallelGC 启用此算法）可以并行运行次要收集。 警告：该算法是“停止世界”的算法，但可以使用多个处理器来执行GC。
还有 -XX：+ UseParallelOldGC ，它们为旧的GEN启用了收集器。
这些算法从VM变为另一个。因此，请查看您正在使用的JVM版本，并尝试根据您的需要选择正确的算法。
正如Peter在回答中所说，分析器将帮助您评估您的应用程序，所选择的GC算法并做出决定。