Java垃圾回收日志中的“ GC--”是什么意思？

Question

我們打開了詳細的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--”是什么意思？

Answer 1

我在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 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("--");
  }
}

使用並行Scavenge收集器進行GC的原因

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響應疏散失敗。

Answer 2

我從這里得到以下內容：

前兩行表示您有兩個次要收藏，一個主要收藏。 箭頭之前和之后的數字分別表示垃圾回收之前和之后的活動對象的組合大小。 在進行次要收集之后，計數中包括不一定處於活動狀態但無法回收的對象，這是因為它們是直接存在的，或者是因為它們在受權保護的一代之內或從其繼承而來。 括號中的數字是總可用空間，不包括永久代中的空間，即總堆減去一。第三行中主要集合的格式與此類似。 標志-XX：+ PrintGCDetails打印有關集合的其他信息。 帶有此標志的附加信息可能會隨虛擬機的每個版本而變化。 帶有-XX：+ PrintGCDetails標志的附加輸出尤其會隨着Java虛擬機的開發需求而變化。 幸存空間。 次要收藏大約花費了四分之一秒。

Answer 3

實際上，在我們自己的日志中遇到此問題之后，我和一位同事有另一種解釋似乎更符合事實。

在此示例中，您會注意到Full GC遵循這條怪異的次要GC行。 我可以確認，當它出現在我們的日志中時，總是這樣。 您還可以看到Young Gen的開始大小和結束大小相等，我可以再次確認情況始終如此。

我們認為，這里發生的情況是VM已啟動了次要GC，在無法釋放任何東西或花費了太長時間而無法釋放任何東西之后，決定改為執行完全備份。

Answer 4

它不在Java GC常見問題上

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（）嗎？

Answer 5

Yishai在評論中說：

給定時間戳和內存量，我猜它會執行垃圾回收，但是會丟失可用內存（因為其他對象是並行創建的）