我使用了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]
基於閱讀http://blogs.oracle.com/poonam/entry/understanding_cms_gc_logs CMS將做在各種情況下一個完整的垃圾收集(例如,如果「掃毒嘗試中的提升失敗」),但根據該博客,它將記錄完整GC的原因。
相反,我看到的adhoc全選區。它絕對是CMS,因爲還有其他CMS日誌條目。
是否有原因,會做一個完整的GC,但無法登錄的原因?
編輯: 對不起,多個Java安裝(我繼承此設置)。它實際上是用jdk1.6.0_27
編輯 不幸的是,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
你能告訴我們你正在使用的JVM參數嗎? – 2012-01-17 11:58:21
我沒有想到Java 5.0支持'-XX:+ UseCompressedOops' – 2012-01-17 14:01:01
您需要添加-verbose:gc以獲得更多關於正在發生的事情的信息 – Matt 2012-01-17 14:11:22