Java CMS垃圾收集器日志输出

我正在使用Java CMS垃圾收集器，并试图理解以下日志行：

22609.787: [GC 22609.788: [ParNew: 1116101K->79200K(1310720K), 0.2369136 secs]     1551730K->516431K(6029312K), 0.2379422 secs] [Times: user=1.68 sys=0.02, real=0.24 secs] 
22610.741: [Full GC 22610.741: [CMS: 437230K->278442K(4718592K), 14.8596841 secs]   573355K->278442K(6029312K), [CMS Perm : 241468K->236967K(241856K)], 14.8694544 secs]   [Times: user=14.80 sys=0.13, real=14.87 secs] 
22635.415: [GC 22635.416: [ParNew: 1048576K->43613K(1310720K), 0.0904065 secs] 1327018K->322055K(6029312K), 0.0914701 secs] [Times: user=0.45 sys=0.00, real=0.09 secs] 

基于阅读，CMS将在各种情况下进行完全垃圾收集（例如，如果“清除尝试中的升级失败”），但根据该博客，它将记录完整GC的原因

相反，我看到的是临时全面GCs。它肯定是CMS，因为还有其他CMS日志条目

是否有理由做一个完整的GC，但不记录原因

编辑： 抱歉，多个java安装（我继承了此设置）。它实际上使用的是jdk1.6.027

编辑 不幸的是，JVM参数被包装在配置文件中（这是一个在Tomcat上运行的商业应用程序），但我很确定它们是：

min.heapsize=6144m
max.heapsize=6144m
-Xss=512k
-XX:MaxPermSize=512m
-XX:NewSize=1536m 
-XX:MaxNewSize=1536m 
-XX:SurvivorRatio=4 
-XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC 
-XX:+UseTLAB 
-XX:+UseCompressedOops 
-XX:+PrintVMOptions 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCTaskTimeStamps
-XX:+PrintCommandLineFlags 
-XX:+PrintGCApplicationStoppedTime 
-XX:StackShadowPages=20 
-XX:+DisableExplicitGC 

---

当ConcurrentMarkSweepGC确定它即将填充或已达到其低水位线时，它将执行GC。（我不相信这里的情况）

更有可能的是，某些代码正在直接调用System.gc（）。例如，RMI默认每小时调用一次。您可以尝试使用

-XX:+DisableExplicitGC

来查看它是否有作用。如果是这样，我会找出原因并阻止它发生（有些人只是让这个选项保持开启状态）

另一个可能的原因是可用直接内存不足。直接内存仅在GC上清理，但对堆大小影响不大，因此看起来确实需要GC。当直接内存用完时，它必须调用System.gc（）来释放使用它的字节缓冲区。我绕过它的方法是明确地清除直接和内存映射的缓冲区，这样我就不会耗尽内存

另外，我会尝试Java6Update30，甚至Java7Update2，因为它可能具有更可预测的行为（即使您不能使用它，它也可以提供信息）

您可以尝试告诉您触发了什么GC（但并不总是）

---

你能告诉我们你在使用什么JVM参数吗？我不认为Java 5.0支持

-XX:+UseCompressedOops

，你需要添加-verbose:gc来获得更多关于正在发生什么的信息。谢谢，我已经在运行

-XX:+DisableExplicitGC

时启用了，所以我猜它不是RMI。什么是“直接记忆”？谷歌最接近的是“直接缓冲存储器”，这是同一回事吗？System.gc（）是否不使用并发gc（由-XX:+UseConcMarkSweepGC指定），而是强制使用普通gc？System.gc（）将触发一个未计划的完整gc，因此它不会并发，并且将是一个完整的STW暂停

`jstat -gccause {pid} 10s`