“垃圾收集日志”中的“GC–”是什么意思？
我们打开了详细的GC日志记录来跟踪已知的内存泄漏并在日志中获得以下条目：
... 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] ... 我理解第一个和第三个，但“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”是一个停止世界的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 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("--"); } }
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
使用G1收集器的GC的原因
G1的疏散失败是当幸存者区域没有足够空间容纳来自Young Region的幸存物体时。
我不知道G1收集器是否用Full GC响应疏散失败。
我从这里得到以下内容：
前两行表示您有两个次要集合和一个主要集合。 箭头前后的数字分别表示垃圾收集前后活动对象的总大小。 在次要集合之后，计数包括不一定存活但无法回收的对象，因为它们直接存活，或者因为它们在终身代内或从其中引用。 括号中的数字是总可用空间，不包括永久代中的空间，即总堆减去1。第三行中主要集合的格式类似。 标志-XX：+ PrintGCDetails打印有关集合的其他信息。 使用此标志打印的附加信息可能随每个版本的虚拟机而更改。 带有-XX：+ PrintGCDetails标志的附加输出尤其随着Java虚拟机开发的需要而变化。 幸存者空间。 次要collections大约花了四分之一秒。
实际上，在我们自己的日志中遇到这个后，我和一个同事有一个替代解释，似乎更紧密地符合事实。
在这个例子中你会注意到Full GC遵循这个奇怪的次要GC线。 我可以确认，当它在我们的日志中出现时总是如此。 您还可以看到Young Gen的开始和结束大小相等，我可以再次确认情况总是如此。
我们相信这里发生的事情是VM已经开始使用Minor GC，并且在无法释放任何内容或花费太长时间而无法释放任何内容之后，决定执行Full。
它不在Java GC FAQ上
http://java.sun.com/docs/hotspot/gc1.4.2/faq.html
也不像Java GC示例页面中提到的那样
http://java.sun.com/docs/hotspot/gc1.4.2/example.html
我以前从未见过。
你有没有特殊的垃圾收集器运行？ 你在运行什么VM？ 它是否始终在Full GC之前发生？ 你在调用System.gc（）吗？
Yishai在评论中说：
给定时间戳和内存量，我猜它会执行垃圾收集但丢失可用内存（因为其他对象是并行创建的）