Full GC（堆检查发起的GC）答案

【问题标题】：Full GC (Heap Inspection Initiated GC)Full GC（堆检查发起的GC）
【发布时间】：2020-01-18 18:56:07
【问题描述】：

我正在努力寻找生产 JVM 上的“Full GC”。每天午夜左右，STW 会毫无缘由地发生，持续 10-11 秒非常致命。这是 gc 日志：

Java HotSpot(TM) 64-Bit Server VM (25.131-b11) for windows-amd64 JRE (1.8.0_131-b11), built on Mar 15 2017 01:23:53 by "java_re" with MS VC++ 10.0 (VS2010)
Memory: 4k page, physical 16584284k(13074876k free), swap 23137624k(18439472k free)
CommandLine flags: -XX:GCLogFileSize=1024000 -XX:InitialHeapSize=11811160064 -XX:+ManagementServer -XX:MaxHeapSize=11811160064 -XX:NumberOfGCLogFiles=10 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseGCLogFileRotation -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC 
...
2020-01-17T00:00:04.411+0200: 113734.053: [GC (Heap Inspection Initiated GC) [PSYoungGen: 522474K->146371K(3387904K)] 6946079K->6573263K(11077632K), 0.1786961 secs] [Times: user=0.67 sys=0.02, real=0.18 secs] 
2020-01-17T00:00:04.592+0200: 113734.233: [Full GC (Heap Inspection Initiated GC) [PSYoungGen: 146371K->0K(3387904K)] [ParOldGen: 6426892K->3217828K(7689728K)] 6573263K->3217828K(11077632K), [Metaspace: 81937K->81809K(1126400K)], 11.4447857 secs] [Times: user=44.06 sys=0.20, real=11.44 secs]

“Heap Inspection Initiated GC”究竟是什么意思？谁发起了这项检查，为什么？除了它是由我们不使用的一些工具（如 jmap、jmc..）引起的之外，我没有找到任何有意义的信息。

高度赞赏任何提示或方向。

【问题讨论】：

不要误会我的意思，但您使用的是ParallelGC 并想知道为什么您会得到一个大的 STW？只是想知道......
是的，这是 ParallelGC。问题实际上是 - “Heap Inspection Initiated GC”原因实际上意味着什么。显然原因不是缺少堆，需要清理。此 VM 中有大量堆。
您必须用@ 标记我，我才能知道您已回复。你有可能是这样做的代理人吗？可能是this被触发了？
@Eugene - 好的，这敲响了警钟。我们使用this 进行监控。我要检查一下。如果我理解正确，这个 GC 可能是由外部进程引起的，而不是由它本身引起的？这就是这个原因的意思吗？
完全正确。据我所知，有很多地方可以触发：代理、jmap、jfr、SIGBREAK

标签： java garbage-collection jvm

【解决方案1】：

JVM 代理可以触发heap inspection too。要知道当前对象的活跃度，您需要触发Full GC 调用。我想在Shenandoah 和/或ZGC 的情况下，这会“便宜”很多，因为它们与您的应用程序同时工作。更有趣的是，至少在理论上，并发 GC 不需要触发所有阶段（mark 就足够了）来找到什么是活的和/或死的.但是，我怀疑他们不这样做compaction 也。

如果您真的关心STW 事件，那么ParallelGC 可能不是一个很好的选择。 Parallel 以垃圾算法的名义应该敲响警钟：它的所有阶段都与应用程序并行；不并发。

【讨论】：

感谢您的领导！问题是伤口 - 代理（在我们的例子中是“perfino”）。它的默认值之一（记录定期堆快照）设置为 24 小时。这导致每个午夜在受监控的 JVM 上进行 Full GC。馊主意。 @Ingo Kegel - 仅供参考。

【解决方案2】：

引用Spectator Docs - GC Causes:

Heap_Inspection_Initiated_GC

GC 由堆上的检查操作启动。例如，您可以使用jmap 触发此操作：
$ jmap -histo:live <pid>

另请参阅Does JMC Flight Recording force Full GC?（答案：是的，如果启用了堆统计信息）
另见Will jcmd PID GC.class_histogram call a full GC before collecting data?（答案：是）

【讨论】：

谢谢，我看到了这些……但是我们不使用任何外部进程来触发正在运行的 VM 上的 GC。
@Dima 你显然是wrong 。
是的，我错了，因为我没有意识到分析器代理能够做到这一点。
JFR 不会导致完全 GC，除非您明确启用堆统计信息，或者使用 jcmd JFR.dump path-to-gc-roots=true 转储重新编码。
@KireHaglin 是的，这正是链接的answer 所说的，那么你的意思是什么？