是否可以使用jmx监控gc紧凑化？

Question

我可以从jmx中检索GarbageCollectionMXBean。但是，如何区分 major gc和 full gc？这是非官方的条款。如果老一代被清理，我将gc表示为 major 。并且 full 我指的是压缩（碎片整理）堆的gc。从实际角度看，当并发模式失败或程序员明确调用System.gs

时，会出现完整的gc

是否可以用jmx区分这些事件？

Answer 1

两个警告词：

• 请注意，正如您所定义的那样，“major”gc不一定排除压缩（例如，G1GC在主要循环上执行增量压缩）。因此，您将“主要”与“完整”事件区分开来的问题与“压缩”与“非紧凑”事件不同。我知道你对后者更感兴趣，但请让我知道。
• 有关收集器的详细信息是特定于JVM的。我将回答HotSpot，但这可能对其他实现无效。

AFAIK，JMX bean中没有关于压缩和非压缩事件的数据。 JMX提供了关于每个收集器的（在java.lang：type = GarbageCollector内部）统计信息，因此了解每个收集器阶段的一些细节，您可以对压缩事件进行合理的推断。

例如，ConcurrentMarkSweep收集器（-XX：+ UseConcMarkSweepGC）不紧凑（因此，您无法使用这些事件）。但是，当CMS无法释放足够的空间（通常是由于碎片）时，它将为下一个事件安排MarkSweepCompact。这些事件将是一个压缩事件，我相信它们应该出现在java.lang：name = MarkSweepCompact，type = GarbageCollector）。

G1GC（Java 8的默认设置），在每个事件中执行增量压缩，因此我不确定GC事件是否特别有用。

Parallel收集器压缩旧一代，正确的MBean应该是java.lang：type = GarbageCollector，name = PS MarkSweep。

有用的文档： - HotSpot GC文档（java8）：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html - 快速参考大多数收藏家（但旧）https://blogs.oracle.com/jonthecollector/our-collectors - 作为不同JVM实现的示例，Zing不断压缩收集器：http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf