了解 Java 11 中的 GC1 日志文件答案

【问题标题】：Understanding GC1 log file in java 11了解 Java 11 中的 GC1 日志文件
【发布时间】：2022-01-14 15:26:00
【问题描述】：

作为Java 11 GC logging 中问题的一部分，我很难理解这些数字的实际含义。

例如：

  [2020-07-14T10:01:14.791-0400][gc            ] GC(353) Pause Young (Normal) (G1 Evacuation Pause) 163M->16M(248M) 1.689ms
[2020-07-14T10:01:14.790-0400][gc,heap       ] GC(353) Eden regions: 147->0(147)
[2020-07-14T10:01:14.790-0400][gc,heap       ] GC(353) Survivor regions: 1->1(19)
[2020-07-14T10:01:14.790-0400][gc,heap       ] GC(353) Old regions: 16->16
[2020-07-14T10:01:14.790-0400][gc,heap       ] GC(353) Humongous regions: 1->1

我知道147->0 是在收集之前/之后，但是这里的单位和下面的单位是什么？如我所见，整个年轻代是否从 163M 减少到 16M ，看起来这也几乎完全发生在伊甸园区域内 - 所以对象甚至在移动到幸存者空间之前就已经超出范围？

【问题讨论】：

单位似乎与摘要条目的单位匹配，即163M->16M，与147->0有相同的区别。所以这可能意味着 147M 已经完全从伊甸园空间收集。但这也可能意味着一些对象已从 Eden 移动到 Survivor 空间，而具有相同总内存量的对象已在同一周期从 Survivor 空间收集。
是否有可能在同一个周期内，内存进入幸存者空间，然后被收集。这听起来效率较低。如果我知道大多数对象只存在于伊甸园空间中，是否有任何关于如何优化这一点的参考？
在一个年轻的集合Eden 和其中一个幸存者Survivor-from 之后，总是被完全删除。
@A2LBK 不，我说的是这样一种场景，即大量对象被复制到幸存者空间，而相同数量的不同对象从幸存者空间中收集同一个周期，看这个数字你不会注意到。这并不意味着有什么需要优化的。您正在查看错误的数字。查看应用程序的 CPU 消耗及其用于垃圾收集的部分。多少钱？如果是，例如1%，这意味着无论你怎么努力，优化垃圾收集的 CPU 性能永远不会超过 1%。

标签： garbage-collection java-11

【解决方案1】：

这里的单位是什么

A region。区域大小因堆大小或显式设置而异。

看起来这几乎完全发生在伊甸园区域内 - 所以这些物体甚至在移动到幸存者空间之前就已经超出了范围？

它们中的大多数，少量可能仍会流入后代，但另一方面，这些区域也可能包含可以收集的现已死亡的对象，因此它们大部分处于平衡状态，只有非常少量的流向老年代。这种行为是分代收集器如此高效的原因。

【讨论】：