为什么在启动jvm时在老年代使用0K时触发cms收集？答案

【问题标题】：Why trigger cms collect when 0K use in old generation when start jvm?为什么在启动jvm时在老年代使用0K时触发cms收集？
【发布时间】：2019-06-24 18:27:30
【问题描述】：

当我启动 jvm (jdk 8) 时，我发现这个 cms gc log 。它显示老年代使用 0K (0K(1747648K))，但 jvm 执行 cms collect 。为什么？

2019-01-31T18:00:28.603+0800: 4.466: [GC (CMS Initial Mark) [1 CMS-initial-mark: 0K(1747648K)] 65577K(2534080K), 0.0077440 secs] [Times: user=0.03 sys=0.00, real=0.01 secs] 
2019-01-31T18:00:28.611+0800: 4.474: [CMS-concurrent-mark-start]
2019-01-31T18:00:28.627+0800: 4.490: [CMS-concurrent-mark: 0.016/0.016 secs] [Times: user=0.06 sys=0.01, real=0.02 secs] 
2019-01-31T18:00:28.627+0800: 4.490: [CMS-concurrent-preclean-start]
2019-01-31T18:00:28.630+0800: 4.493: [CMS-concurrent-preclean: 0.003/0.003 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 
2019-01-31T18:00:28.630+0800: 4.493: [CMS-concurrent-abortable-preclean-start]
2019-01-31T18:00:29.748+0800: 5.611: [CMS-concurrent-abortable-preclean: 0.824/1.117 secs] [Times: user=4.06 sys=0.13, real=1.12 secs] 
2019-01-31T18:00:29.749+0800: 5.612: [GC (CMS Final Remark) [YG occupancy: 437791 K (786432 K)]2019-01-31T18:00:29.749+0800: 5.612: [Rescan (parallel) , 0.2379222 secs]2019-01-31T18:00:29.987+0800: 5.850: [weak refs processing, 0.0000407 secs]2019-01-31T18:00:29.987+0800: 5.850: [class unloading, 0.0058594 secs]2019-01-31T18:00:29.993+0800: 5.856: [scrub symbol table, 0.0026897 secs]2019-01-31T18:00:29.995+0800: 5.858: [scrub string table, 0.0006242 secs][1 CMS-remark: 0K(1747648K)] 437791K(2534080K), 0.2489874 secs] [Times: user=0.96 sys=0.02, real=0.25 secs]

下面是我的jvm选项：

 -server -Xms2560m -Xmx2560m -XX:MaxPermSize=256m 
 -XX:+UnlockExperimentalVMOptions -Dcom.sun.management.jmxremote 
 -Dcom.sun.management.jmxremote.port=52001 -Dcom.sun.management.jmxremote.authenticate=false
  -Dcom.sun.management.jmxremote.ssl=false  -XX:+UseConcMarkSweepGC 
  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=test 
  -XX:+PrintGCDateStamps -XX:+PrintGCDetails 
  -Xloggc:gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=10M

【问题讨论】：

您有哪些 GC 选项？如果您错误地配置了 IHOP，它可能会通过填充年轻的 GC 来触发旧的 GC。
@the8472 查看我的更新。
-XX:MaxPermSize=256m 在 Java 8 下毫无意义。您甚至应该在日志中看到一条警告，指出此选项将被忽略。此外，-server 对于 64 位 JVM 来说已经过时了，因为没有其他的了。
@Holger 你是对的，但它与这个问题无关。

标签： garbage-collection jvm

【解决方案1】：

显示老年代使用 0K (0K(1747648K))

这可能是由于启动堆占用启发式设置了一个非常低的值。尝试显式设置-XX:InitiatingHeapOccupancyPercent=80 -XX+UseCMSInitiatingOccupancyOnly，仅当堆的 80% 已满时才会启动。

【讨论】：

它不起作用，当我设置-XX:InitiatingHeapOccupancyPercent=80 -XX+UseCMSInitiatingOccupancyOnly时，它仍然得到这个gc日志。

【解决方案2】：

-XX:+PrintTenuringDistribution 和 -XX:+PrintGCCause 给出的原因是什么？

【讨论】：