Java GC 不明确的日志消息

Question

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

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

我的 jar 包含大量数据( double 表，600 MB)，这些数据在应用程序的整个生命周期内都保留在内存中。

然后它会给出日志消息，大约每分钟，说:

[GC [DefNew: 279616K->279616K(314560K), 0.0002037 secs][Tenured: 595827K->599952K(699072K), 1.1020398 secs] 875443K->599952K(1013632K), [Perm : 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 中，它确实加起来了，所以我可能遗漏了什么。

Answer 1

重点是 DefNew 和 Tenured 是次要收集的结果，而总数还包括以下主要收集的结果。因此，新生代在minor collection中无法被成功回收，只能被major collection回收。

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]

This is an example of the relative size of the young generation to the tenured generation being too large to allow the young generation promotion to be guaranteed (the young generation is about half the size of the tenured generation). The young generation cannot be collected successfully and only major collections are occurring. Note that in this cause the young generation is collected but only as part of the more expensive major collection.

我想在你的情况下，这也可能是由于老年代的可用空间不足造成的。