Java 完全GC（堆检查启动GC）

我正在努力寻找生产JVM上的“完整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] 

“堆检查启动GC”实际上是什么意思？谁发起这次检查？为什么？我找不到关于它的任何有意义的信息，除了它是由诸如jmap、jmc之类的工具引起的。。我们不用它

任何提示或指示都将受到高度赞赏。

引用：

堆检查\u启动\u GC GC是由堆上的检查操作启动的。例如，您可以通过以下方式触发：

$jmap-histo:live

另请参见（回答：是，如果启用了堆统计信息）

---

另请参见（回答：是）

JVM代理可以触发一个。要了解当前对象的活跃度，需要触发

Full GC

调用。我想在

Shenandoah

和/或

ZGC

的情况下，这会“便宜得多”，因为它们与您的应用程序同时工作。更有趣的是，至少在理论上，并发的

GC

不需要触发所有的阶段（

mark

就足够了）来发现什么是活的和/或死的。然而，我怀疑他们是否也做了

压缩

---

如果您真正关心

STW

事件，

ParallelGC

可能不是一个很好的选择

Parallel

以垃圾算法的名义应该会引起注意：它的所有阶段都与应用程序并行；不是并发的

别误会我的意思，但您使用的是

ParallelGC

，不知道为什么会得到一个大的STW？只是想知道…是的，我是ParallelGC。问题实际上是，“堆检查启动GC”的原因实际上意味着什么。很明显，原因不是缺少堆，需要清理。此VM中有大量堆。您必须用

@

标记我，我才能知道您已响应。你有没有可能是这样的代理人？可能是被触发了？@Eugene-好的，这个铃响了。。我们用它来监控。我要去看看这个。如果我理解正确的话，这个GC可能是由外部进程而不是自身引起的？这就是原因的意思吗？没错。据我所知，有很多地方可以触发这种情况：代理、jmap、jfr、

SIGBREAK

谢谢，我看到了这些。。但是，我们不使用任何外部进程在运行VM时触发GC。@Dima您显然是这么想的。是的，我错了，因为我没有意识到探查器代理能够做到这一点。除非显式启用堆统计信息，或者使用jcmd JFR转储重新编码。转储路径到GC根=true。@KireHaglin Ok，添加了说明。感谢您的指导！问题是伤口-代理人（“perfino”在我们的案例中）。它将其中一个默认值（定期记录堆快照）设置为24小时。这导致了每午夜在受监控的JVM上进行完全GC。坏主意@Ingo Kegel-仅供参考。