Java GC 不明确的日志记录消息答案

【问题标题】：Java GC ambiguous logging messageJava GC 不明确的日志记录消息
【发布时间】：2011-03-21 18:41:29
【问题描述】：

我是在 32 位 Windows 上使用 Java JRE 启动 Java 客户端，使用

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

我的 jar 包含大量数据（双精度表，600ish MB），它们在应用程序的整个生命周期中都保留在内存中。

然后它大约每分钟给出一次日志消息，说：

[GC [DefNew: 279616K->279616K(314560K), 0.0002037 secs][Tenured: 595827K->599952K(699072K), 1.1020398 secs] 875443K->599952K), [Per>(1013632) : 10042K->10042K(16384K)], 1.1030218 secs] [Times: user=1.09 sys=0.01, real=1.11 secs]

我真的不明白粗体部分。它说新一代从 279616K 到 279616K（即没有任何变化），老一代略有增加（595827K->599952K），但总的来说它说 875443K->599952K，即减少了约 30%。这怎么可能？

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

【问题讨论】：

您使用 Sun JDK 吗？如果是这样，您可能想看看Java Tuning White Paper。其次，您能否提供更多背景信息？即操作系统，过程数据模型（32 位或 64 位）...
在我想优化某些东西之前，我首先想了解当前日志消息的内容（在我的例子中，NewRatio=4 并且使用并发 GC 修复了我的 troughtput 问题）。

标签： java garbage-collection

【解决方案1】：

重点是 DefNew 和 Tenured 是次要收集的结果，而总数还包括以下主要收集的结果。所以，young generation在minorcollection中无法成功回收，只能通过majorcollection进行回收。

Diagnosing a Garbage Collection problem 提示可能是年轻代过大造成的：

[GC [DefNew: 16000K->16000K(16192K), 0.0000498 secs][Tenured: 2535K->2319K(16384K), 0.0860925 secs] 18535K->2319K(32576K), 0.0863350 secs]

这是一个年轻代与老一代的相对大小太大而无法保证年轻代提升的例子（年轻代大约是老一代大小的一半）。年轻代无法成功收集，仅发生主要收集。请注意，在这种情况下，年轻代会被收集，但只是作为更昂贵的主要收集的一部分。

我猜在你的情况下，这也可能是由于终身代中缺少可用空间造成的。

【讨论】：

谢谢，但我还是不明白Tenured 怎么会成为minor 集合的一部分； minor 集合不就是只收集年轻一代吗？如果它是次要集合的一部分，为什么次要集合大部分时间都花在终身代上？

【解决方案2】：

在询问之前，应该在 SO 中进行更多搜索。不管怎样，看看这个：

Java Garbage Collection Log messages

【讨论】：

Jep，看到了那个帖子和其中的原始链接，所以我尝试在我的日志上检查基础算法，但它没有加起来。在主帖中查看我的编辑。