我可以从 jmx 检索 GarbageCollectionMXBean。但是我如何区分major gc 和full gc？那是非官方术语。如果老年代被清理，我将 gc 表示为major。我所说的“完整”是指压缩(碎片整理)堆的GC。从实际角度来看，当并发模式失败或程序员显式调用 System.gs
是否可以用jmx来区分此类事件？
最佳答案
两句话警告:
- 请注意，正如您所定义的，“主要”GC 并不一定排除压缩(例如，G1GC 在主要周期上执行增量压缩)。因此，区分“主要”事件和“完整”事件的问题与“压缩”事件和“非压缩”事件不同。我知道您对后者更感兴趣，但请告诉我其他情况。
- 有关收集器的详细信息是 JVM 特定的。我会回答 HotSpot，但这可能对其他实现无效。
据我所知，JMX beans 中没有提供有关压缩和非压缩事件的数据。 JMX 确实提供(在 java.lang:type=GarbageCollector 中)有关每个收集器的统计信息，因此了解有关每个收集器阶段的一些详细信息，您可以对压缩事件做出合理的推断。
例如，ConcurrentMarkSweep 收集器 (-XX:+UseConcMarkSweepGC) 不压缩(因此，您不能使用这些事件)。但是，当 CMS 无法释放足够的空间(通常是由于碎片)时，它将为下一个事件安排 MarkSweepCompact。这些事件将是一个压缩事件，我相信它们应该出现在 java.lang:name=MarkSweepCompact,type=GarbageCollector) 下。
G1GC(Java 8 的默认值)在每个事件中执行增量压缩，因此我不确定 GC 事件是否特别有用。
并行收集器会压缩老年代，正确的MBean应该是java.lang:type=GarbageCollector,name=PS MarkSweep。
有用的文档: - HotSpot GC 文档 (java8): https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html - 快速引用。大多数 Collection 家(但老)https://blogs.oracle.com/jonthecollector/our-collectors - Zing 的连续压缩收集器作为不同 JVM 实现的示例:http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf
关于java - 是否可以使用 jmx 监控 gc 压缩？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44467823/