java - 监控IntelliJ 2018.03时出现这么多Major GC？

Question

Major GC由 System.gc() 触发.

为了避免在启动 IntelliJ 2018.3 时出现大量主要 GC，我尝试使用以下 VM 选项配置 idea64.vmoptions

_{(直接从 VisualVM JVM 参数复制)}

-Xms256m
-Xmx2400m
-XX:NewSize=512M
-XX:MaxNewSize=512M
-XX:+UseConcMarkSweepGC
-XX:ReservedCodeCacheSize=240m
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-Xloggc:/home/hearen/.IntelliJIdea2018.3/gc_details.log
-XX:+CITime
-XX:+PrintGCDetails
-Dawt.useSystemAAFontSettings=lcd
-Dsun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine
-XX:ErrorFile=/home/hearen/java_error_in_IDEA_%p.log
-XX:HeapDumpPath=/home/hearen/java_error_in_IDEA.hprof
-Didea.paths.selector=IntelliJIdea2018.3
-Djb.vmOptionsFile=/home/hearen/.IntelliJIdea2018.3/config/idea64.vmoptions
-Didea.jre.check=true

我尝试为Young & Tenured Generation( -Xms512m -Xmx2400m -XX:MaxNewSize=512M -XX:NewSize=512M )提供足够大的内存，尽可能避免 Minor 和 Major GC，并禁用 -XX:+DisableExplicitGC 。

但我仍然在 GC 日志中目睹了很多 Major GC(在 VisualVM 中，我看到 Old Gen 有 18 个 Major GC 回收，Eden 有 14 个)。

据我检查-XX:CMSTriggerRatio默认为 80% 启动 CMS 收集周期，这似乎不是原因，但 GC 日志中有很多 CMS 周期。

2019-03-18T18:53:40.683+0800: 176.928: [GC (CMS Initial Mark) [1 CMS-initial-mark: 54738K(150112K)] 476819K(621920K), 0.0516469 secs] [Times: user=0.20 sys=0.00, real=0.05 secs] 
2019-03-18T18:53:40.734+0800: 176.979: [CMS-concurrent-mark-start]
2019-03-18T18:53:40.797+0800: 177.043: [CMS-concurrent-mark: 0.063/0.063 secs] [Times: user=0.06 sys=0.00, real=0.07 secs] 
2019-03-18T18:53:40.797+0800: 177.043: [CMS-concurrent-preclean-start]
2019-03-18T18:53:40.800+0800: 177.045: [CMS-concurrent-preclean: 0.003/0.003 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 
2019-03-18T18:53:40.800+0800: 177.045: [CMS-concurrent-abortable-preclean-start]
 CMS: abort preclean due to time 2019-03-18T18:53:45.872+0800: 182.117: [CMS-concurrent-abortable-preclean: 3.168/5.072 secs] [Times: user=3.20 sys=0.00, real=5.07 secs] 
2019-03-18T18:53:45.872+0800: 182.117: [GC (CMS Final Remark) [YG occupancy: 423458 K (471808 K)]2019-03-18T18:53:45.872+0800: 182.117: [Rescan (parallel) , 0.0511363 secs]2019-03-18T18:53:45.923+0800: 182.168: [weak refs processing, 0.0000925 secs]2019-03-18T18:53:45.923+0800: 182.168: [class unloading, 0.0183514 secs]2019-03-18T18:53:45.942+0800: 182.187: [scrub symbol table, 0.0381231 secs]2019-03-18T18:53:45.980+0800: 182.225: [scrub string table, 0.0013231 secs][1 CMS-remark: 54738K(150112K)] 478196K(621920K), 0.1099238 secs] [Times: user=0.26 sys=0.00, real=0.11 secs] 
2019-03-18T18:53:45.982+0800: 182.227: [CMS-concurrent-sweep-start]
2019-03-18T18:53:45.998+0800: 182.244: [CMS-concurrent-sweep: 0.016/0.016 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 
2019-03-18T18:53:45.998+0800: 182.244: [CMS-concurrent-reset-start]
2019-03-18T18:53:45.999+0800: 182.245: [CMS-concurrent-reset: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
2019-03-18T18:53:48.000+0800: 184.245: [GC (CMS Initial Mark) [1 CMS-initial-mark: 54738K(150112K)] 478965K(621920K), 0.0538103 secs] [Times: user=0.20 sys=0.00, real=0.05 secs] 

也许有帮助

_{为了确保结果的准确性，我对每个配置都尝试了多次。}

我尝试比较与没有 -XX:NewSize=512M -XX:MaxNewSize=512M

1. 包含:主要 -> 18 和次要 -> 14；
2. 没有(Eden 为 266M):Major -> 10 和 Minor -> 40；

<小时/>

我的问题

1. 为什么有这么多Major GC？
2. 为什么有这么多CMS，是什么触发了它们？
3. 即使我有内存，我也不能同时减少 Minor 和 Major 吗？

任何帮助将不胜感激:)

Answer 1

您在配置中使用 CMS。这意味着三种类型的暂停

1. 次要/年轻系列[ParNew]
2. 并发旧空间集合
3. 完整停止世界单线程最后手段集合

(请参阅 Garbage collection in HotSpot JVM，文章很旧，但解释了 GC 日志片段)

次要和并发都可以。 满不好。

VisualVM 不区分并发和完整，因此“主要”收集的数量对于 CMS GC 来说非常具有误导性。

PS 您可能需要使用“Visual GC”插件来密切观察堆动态。