我在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的回答，这很有意义，但是当JVM在GC日志中打印“-”时，我想在Java GC源代码中亲自查看它，以及为什么。

据我所知，Young Gen的“ Parallel Scavenge”是一个停滞不前的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 Collectorif (evacuation_failed()) {  remove_self_forwarding_pointers();  if (PrintGCDetails) {    gclog_or_tty->print(" (to-space overflow)");  } else if (PrintGC) {    gclog_or_tty->print("--");  }}--# Parallel Scavenge Collectorpromotion_failure_occurred = promotion_failed();if (promotion_failure_occurred) {  clean_up_failed_promotion();  if (PrintGC) {    gclog_or_tty->print("--");  }}

使用GC的原因-使用并行Scavenge收集器

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响应疏散失败。