我们已打开详细 GC 日志记录以跟踪已知的内存泄漏并在日志中获得以下条目:

<代码>...3607872.687:[GC 471630K->390767K(462208K)，0.0325540 秒]3607873.213:[GC-- 458095K->462181K(462208K)，0.2757790 秒]3607873.488:[完整 GC 462181K->382186K(462208K)，1.5346420 秒]...

我理解其中的第一个和第三个，但是GC--"是什么意思?

解决方案

我的 gc 输出中有这些行:

44871.602: [GC-- [PSYoungGen: 342848K->342848K(345600K)] 961401K->1041877K(1044672K), 0.1018780 secs] [Times: user=0.16 sys=0.00, real=0.11 secs]

我阅读了 Yishai 的答案，这很有意义，但我想在 Java GC 源代码中亲自查看，当 JVM 在 GC 日志中打印--"时以及原因.

因为据我所知，Young Gen 的Parallel Scavenge"是一个 stop-the-world GC，所以 不可能有任何对象与此 GC 并行创建.(请参阅 https://blogs.oracle.com/jonthecollector/entry/our_collectors)

您可以在 jdk 源代码中找到它(参见 http://hg.openjdk.java.net/jdk7/jdk7)g1CollectedHeap.cpp 和 psScavenge.cpp

jdk7-ee67ee3bd597/hotspot/src/share$ egrep -h -A2 -B5 -r '"--"' *# G1 收藏家如果(疏散失败()){remove_self_forwarding_pointers();if (PrintGCDetails) {gclog_or_tty->print(" (to-space overflow)");}否则如果(打印GC){gclog_or_tty->print("--");}}--# 并行清理收集器Promotion_failure_occurred = Promotion_failed();如果(promotion_failure_occurred){clean_up_failed_promotion();如果(打印GC){gclog_or_tty->print("--");}}

GC 的原因——使用 Parallel Scavenge Collector

Young GC 遇到升级失败(参见 http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2010-March/000567.html):

<块引用><块引用>

升级失败是一种没有成功的清理，因为旧代中没有足够的空间来执行所有需要的升级.清道夫本质上是展开，然后完成整个堆的完整 STW 压缩.

'没有足够的空间'并不一定意味着旧的空间不够，而是旧的空间严重碎片化(参见http://blog.ragozin.info/2011/10/java-cg-hotspots-cms-and-heap.html):

<块引用><块引用>

[...] 不可能找到一定数量的连续内存来提升特定的大对象，即使空闲字节的总数足够大.

这两个 JVM 选项可以帮助您分析堆碎片(参见 http://blog.ragozin.info/2011/10/java-cg-hotspots-cms-and-heap.html):

-XX:+PrintPromotionFailure-XX:PrintFLSStatistics=1

GC 的原因——使用 G1 收集器

G1 的疏散失败是当幸存者区域没有足够的空间容纳来自年轻区域的幸存对象时.

我不知道 G1 收集器是否以 Full GC 响应疏散失败.

We've turned on verbose GC logging to keep track of a known memory leak and got the following entries in the log:

...
3607872.687: [GC 471630K->390767K(462208K), 0.0325540 secs]
3607873.213: [GC-- 458095K->462181K(462208K), 0.2757790 secs]
3607873.488: [Full GC 462181K->382186K(462208K), 1.5346420 secs]
...

I understand the first and third of those, but what does the "GC--" one mean?

解决方案

I got these kind of lines in my gc output:

44871.602: [GC-- [PSYoungGen: 342848K->342848K(345600K)] 961401K->1041877K(1044672K), 0.1018780 secs] [Times: user=0.16 sys=0.00, real=0.11 secs]

I read Yishai's answer and it would make sense, but I wanted to see it for myself in the Java GC source code, when the JVM prints "--" in the GC log and why.

Because to my knowledge "Parallel Scavenge" of the Young Gen is a stop-the-world GC, so there couldn't be any objects created parallel to this GC. (see https://blogs.oracle.com/jonthecollector/entry/our_collectors)

You can find this in the jdk source code (see http://hg.openjdk.java.net/jdk7/jdk7) g1CollectedHeap.cpp and psScavenge.cpp

jdk7-ee67ee3bd597/hotspot/src/share$ egrep -h -A2 -B5 -r '"--"' *
# G1 Collector
if (evacuation_failed()) {
  remove_self_forwarding_pointers();
  if (PrintGCDetails) {
    gclog_or_tty->print(" (to-space overflow)");
  } else if (PrintGC) {
    gclog_or_tty->print("--");
  }
}
--
# Parallel Scavenge Collector
promotion_failure_occurred = promotion_failed();
if (promotion_failure_occurred) {
  clean_up_failed_promotion();
  if (PrintGC) {
    gclog_or_tty->print("--");
  }
}

Reason for GC-- with the Parallel Scavenge Collector

The Young GC encountered a promotion failure (see http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2010-March/000567.html):

A promotion failure is a scavenge that does not succeed because there is not enough space in the old gen to do all the needed promotions. The scavenge is in essence unwound and then a full STW compaction of the entire heap is done.

'Not enough space' doesn't necessarily mean that there isn't enough space in old, but that the old space is heavily fragmented (see http://blog.ragozin.info/2011/10/java-cg-hotspots-cms-and-heap.html):

[...] it is impossible to find certain amount of continuous memory to promote particular large object, even though total number of free bytes is large enough.

These two JVM options could help you analyze your heap fragmentation (see http://blog.ragozin.info/2011/10/java-cg-hotspots-cms-and-heap.html):

-XX:+PrintPromotionFailure
-XX:PrintFLSStatistics=1

Reason for GC-- with the G1 Collector

A evacuation failure with the G1 is when a Survivor Region hasn't enough space for the surviving objects from a Young Region.

I don't know if the G1 Collector responds to a evacuation failure with a Full GC or not.