簡體   English   中英

如何確定完整gc的原因是擴展元空間?

[英]How to confirm the reason for the full gc is to expand metaspace?

我使用-XX:+UseConcMarkSweepGC使用cms gc-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps來打印詳細信息gc日志。

這是完整的gc日志。

2017-03-20T16:23:07.321-0200: 64.425: [GC (CMS Initial Mark) [1 CMS-initial-mark: 10812086K(11901376K)] 10887844K(12514816K), 0.0001997 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2017-03-20T16:23:07.321-0200: 64.425: [CMS-concurrent-mark-start]
2017-03-20T16:23:07.357-0200: 64.460: [CMS-concurrent-mark: 0.035/0.035 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
2017-03-20T16:23:07.357-0200: 64.460: [CMS-concurrent-preclean-start]
2017-03-20T16:23:07.373-0200: 64.476: [CMS-concurrent-preclean: 0.016/0.016 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
2017-03-20T16:23:07.373-0200: 64.476: [CMS-concurrent-abortable-preclean-start]
2017-03-20T16:23:08.446-0200: 65.550: [CMS-concurrent-abortable-preclean: 0.167/1.074 secs] [Times: user=0.20 sys=0.00, real=1.07 secs]
2017-03-20T16:23:08.447-0200: 65.550: [GC (CMS Final Remark) [YG occupancy: 387920 K (613440 K)]65.550: [Rescan (parallel) , 0.0085125 secs]65.559: [weak refs processing, 0.0000243 secs]65.559: [class unloading, 0.0013120 secs]65.560: [scrub symbol table, 0.0008345 secs]65.561: [scrub string table, 0.0001759 secs][1 CMS-remark: 10812086K(11901376K)] 11200006K(12514816K), 0.0110730 secs] [Times: user=0.06 sys=0.00, real=0.01 secs]
2017-03-20T16:23:08.458-0200: 65.561: [CMS-concurrent-sweep-start]
2017-03-20T16:23:08.485-0200: 65.588: [CMS-concurrent-sweep: 0.027/0.027 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
2017-03-20T16:23:08.485-0200: 65.589: [CMS-concurrent-reset-start]
2017-03-20T16:23:08.497-0200: 65.601: [CMS-concurrent-reset: 0.012/0.012 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

我如何確認完整gc的原因是擴展元空間?

對於Java 8:

元空間容量

默認情況下,類元數據分配受可用本機內存量限制(容量將取決於您是否使用32位JVM與64位以及操作系統虛擬內存的可用性)。 一個新的標志(MaxMetaspaceSize)可用,允許您限制用於類元數據的本機內存量。 如果不指定此標志,則Metaspace將在運行時根據應用程序需求動態調整大小。

元空間垃圾收集

一旦類元數據使用量達到“ MaxMetaspaceSize”,就會觸發死類和類加載器的垃圾收集。 為了限制此類垃圾收集的頻率或延遲,顯然將需要對Metaspace進行適當的監視和調整。 過多的Metaspace垃圾回收可能是類的征兆,類裝入器的內存泄漏或應用程序的大小不足。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM