我已将java配置为将垃圾收集信息转储到日志中(verbose GC)。我不确定日志中的垃圾收集条目是什么意思。这些条目的样本发布在下面。我在Google上搜索过,但没有找到可靠的解释。
我有一些合理的猜测,但我正在寻找答案,这些答案提供了条目中数字的严格定义,并由可靠的消息来源支持。对所有引用sun文档的答案自动+1。我的问题是:
8109.128:[GC [PSYoungGen:109884K-> 14201K(139904K)] 691015K-> 595332K(1119040K),0.0454530 秒]
8112.111:[GC [PSYoungGen:126649K-> 15528K(142336K)] 707780K-> 605892K(1121472K),0.0934560 秒]
8112.802:[GC [PSYoungGen:130344K-> 3732K(118592K)] 720708K-> 607895K(1097728K),0.0682690 秒]
答案 0 :(得分:125)
相关完整GC的示例还显示了用于旧代和永久代的收集器:
3.757: [Full GC [PSYoungGen: 2672K->0K(35584K)]
[ParOldGen: 3225K->5735K(43712K)] 5898K->5735K(79296K)
[PSPermGen: 13533K->13516K(27584K)], 0.0860402 secs]
最后,分解示例日志输出的一行:
8109.128: [GC [PSYoungGen: 109884K->14201K(139904K)] 691015K->595332K(1119040K), 0.0454530 secs]
答案 1 :(得分:90)
大部分内容都在GC Tuning Guide中解释(无论如何你都会很好地阅读)。
命令行选项
-verbose:gc
会在每个集合中打印有关堆和垃圾回收的信息。例如,这是从大型服务器应用程序输出:[GC 325407K->83000K(776768K), 0.2300771 secs] [GC 325816K->83372K(776768K), 0.2454258 secs] [Full GC 267628K->83769K(776768K), 1.8479984 secs]
在这里,我们看到两个小集合,后面跟着一个主要集合。箭头之前和之后的数字(例如,来自第一行的
325407K->83000K
)分别指示垃圾收集之前和之后的活动对象的组合大小。在次要集合之后,大小包括一些垃圾(不再存活)但无法回收的对象。这些对象或者包含在终身代中,或者从终身代或永久代引用。括号中的下一个数字(例如,来自第一行的
(776768K)
)是堆的已提交大小:可用于java对象的空间量,而无需从操作系统请求更多内存。请注意,此数字不包括幸存者空间之一,因为在任何给定时间只能使用一个幸存者空间,并且不包括永久生成,其中包含虚拟机使用的元数据。该行的最后一项(例如
0.2300771 secs
)表示执行收集所需的时间;在这种情况下大约四分之一秒。第三行中主要集合的格式类似。
-verbose:gc
生成的输出格式可能会在以后的版本中发生变化。
我不确定为什么你的PSYoungGen会出现;你改变了垃圾收集器吗?
答案 2 :(得分:23)