Java的GC暧昧日志消息

我开始在Java客户端的Java JRE的32位的窗口，与Java的GC暧昧日志消息

java -Xmx1024m -Xms1024m -verbose:gc -XX:+PrintGCDetails -jar myJar.jar

我的罐子中包含大量的数据，其留在（双打，600ish MB的表）内存为应用程序的整个生命周期。

它然后给出记录消息，约每分钟，说：

[GC [DefNew：279616K-> 279616K（314560K），0.0002037秒] [终身：595827K-> 599952K（699072K），1.1020398秒] 875443K-> 599952K（1013632K），[彼尔姆：10042K-> 10042K（16384K）]，1.1030218秒] [时间：用户= 1.09 SYS = 0.01，真= 1.11秒]

和我真的不明白大胆的部分。它说新一代从279616K变为279616K（即没有任何变化），老一代略有增加（595827K-> 599952K），但总计说875443K-> 599952K，即减少了约30％。怎么会这样？

编辑：要完全清楚，我期望如果我添加279616K + 595827K = 875443K，我会以粗体显示第一部分，即总堆大小。同样地，我预计279616K + 599952K会以粗体显示第二部分，但不会。在下面指定的链接Java Garbage Collection Log messages中，它确实是加起来的，所以我可能错过了一些东西。

来源

2011-03-21 Frank Meulenaar

您是否使用Sun JDK？如果是这样，你可能想看看[Java调优白皮书]（http://java.sun.com/performance/reference/whitepapers/tuning.html）。其次，你能提供更多的背景吗？即操作系统，过程数据模型（32位或64位）... – 2011-03-21 19:12:00

我首先想了解当前日志消息说什么之前，我想优化一些东西（在我的情况下，NewRatio = 4并使用并发GC解决了我的问题）。 – 2011-03-21 19:33:05

的一点是，DefNew和Tenured都是次要的收藏成果，而总人数还包括了以下主要收集的结果。因此，年轻一代在小规模收集期间不能成功收集，只能由主要收集品收集。

Diagnosing a Garbage Collection problem表明，它可通过年轻一代过大引起的：

[GC [DefNew：16000K-> 16000K（16192K），0.0000498秒] [终身：2535K-> 2319K（16384K），0.0860925秒] 18535K-> 2319K（32576K），0.0863350秒]

这是一个例子，说明年轻一代和终身一代的相对规模太大，不能保证年轻一代的晋升（青年世代约为年龄的一半）。年轻一代不能成功收集，只有主要收藏发生。请注意，在这个原因中，年轻一代是收集的，但只是作为更昂贵的主要收藏的一部分。

我想在你的情况下，它也可能是由于在终身的一代缺乏自由空间造成的。

来源

2011-03-21 19:55:04 axtavt

谢谢，但我仍然不明白'tenured'如何成为* minor *集合的一部分;是不是一个*未成年人的收藏只收集年轻一代？如果它是次要收藏的一部分，为什么小型收藏大部分时间都花在时代上？ – 2011-03-27 12:11:31

在询问之前，应该在SO中多搜索一下。总之，看看这个：

Java Garbage Collection Log messages

来源

2011-03-21 19:15:54 Alfabravo

Jep，看到那篇文章和原来的链接，所以我试图检查我的日志基础aritmetic，但它没有加起来。在主文章中查看我的编辑。 – 2011-03-21 19:32:21

Java的GC暧昧日志消息

回答

相关问题