我们正在使用以下启动参数运行 JBoss，但遇到了长 GC 时间(>5 分钟)的问题。
-Xms116042m -Xmx116042m -XX:PermSize=256M -XX:MaxPermSize=256M -XX:+UseConcMarkSweepGC -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:MaxHeapFreeRatio=95
关于我们如何最小化 GC 时间有什么建议吗？
注意:这些是 16 个四核 cpu，128GB 的 linux 机器。
GC 日志:
我在 GC 日志中看到许多 “CMSbailing out to foreground collection” 消息:
130904.206: [GC 130904.206: [ParNew: 240819K->25522K(249216K), 0.2391170 secs] 80798776K->80588205K(118799360K), 0.2395380 secs] [Times: user=2.56 sys=0.01, real=0.24 secs]
130904.799: [GC 130904.799: [ParNew: 247018K->27648K(249216K), 0.2071170 secs] 80809700K->80601600K(118799360K), 0.2075260 secs] [Times: user=2.61 sys=0.00, real=0.21 secs]
130905.455: [GC 130905.455: [ParNew: 249216K->27648K(249216K), 0.2808950 secs] 80823168K->80644147K(118799360K), 0.2813140 secs] [Times: user=2.66 sys=0.00, real=0.28 secs]
130905.765: [Full GC (System) 130905.765: [**CMSbailing out to foreground collection**
131167.602: [CMS-concurrent-mark: 284.753/303.276 secs] [Times: user=909.49 sys=193.05, real=303.23 secs]
(concurrent mode interrupted): 80616499K->74658646K(118550144K), 554.7507700 secs] 80651365K->74658646K(118799360K), [CMS Perm : 112620K->112582K(262144K)], 554.7511550 secs] [Times: user=784.15 sys=175.10, real=554.65 secs]
131461.127: [GC 131461.128: [ParNew: 221568K->27648K(249216K), 0.2620780 secs] 74880214K->74691531K(118799360K), 0.2624960 secs] [Times: user=2.28 sys=0.00, real=0.27 secs]
131461.698: [GC 131461.699: [ParNew: 249216K->27647K(249216K), 0.3827130 secs] 74913099K->74807895K(118799360K), 0.3829550 secs] [Times: user=3.52 sys=0.41, real=0.39 secs]
131462.754: [GC 131462.754: [ParNew: 249215K->27648K(249216K), 0.3022410 secs] 75029463K->74827673K(118799360K), 0.3026050 secs] [Times: user=2.36 sys=0.02, real=0.30 secs]
131463.789: [GC 131463.790: [ParNew: 249216K->22291K(249216K), 0.2396390 secs] 75049241K->74841234K(118799360K), 0.2400980 secs] [Times: user=2.38 sys=0.06, real=0.24 secs]
最佳答案
无论您使用 conc 标记还是并行 gc，为垃圾清扫 116 Gb 的东西总是会花费很多时间。我总能找到 this document调优 GC 最有用的信息来源。 GC 调整将特定于您的应用需求，没有通用的解决方案，但有许多可用的选项。
使用 G1GC 可能会更幸运，因为它将堆分成许多小部分并独立清除它们，但它仍然可能容易受到随机 OOME 的影响。
如果调整 GC 无法产生足够的响应时间，请将机器拆分为多个 16 到 32 Gb RAM 的虚拟机并将其集群化。如果它是一个 EJB 应用程序，并且您正确地烘烤了您的 bean，它可能不会像看起来那么痛苦。
关于java - 极长的 GC 时间，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13831750/