是否可以在JMX中监控“Full GC”频率（在HotSpot上）？

Question

我想在JMX中监控Full GC频率。 MBean暴露GC计数。 （参见http://download.oracle.com/javase/1.5.0/docs/api/java/lang/management/GarbageCollectorMXBean.html - java.lang：type = GarbageCollector，name =）。

问题是MBean不区分次要和完整的gc。

有人有想法吗？

感谢。

阿尔诺

Answer 1

我对此并不完全确定，但我认为控制所有内存池的垃圾收集器（至少是Old Gen的内存池）是用于主要gc的垃圾收集器。例如：我有一个运行这两个收集器的JVM：

• PS MarkSweep
  • MemoryPoolNames：PS Eden Space，PS Survivor Space，PS Old Gen，PS Perm Gen
  • CollectionCount：68
• PS Scavenge
  • MemoryPoolNames：PS Eden Space，PS Survivor Space
  • CollectionCount：2690

考虑到这一点我会说，PS Scavenge用于主要gc的次要gc和PS MarkSweep。

更新（基于@ajeanson评论，感谢您的反馈btw）：

实际上，我放在那里的例子取自我正在使用的JVM的MXBeans中公开的信息。如您所述，这些是GC算法，GC使用的MXBean的名称基于GC使用的算法。我一直在寻找更多关于此的信息;在本文http://download.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html中，请阅读以下内容：

  

Java HotSpot VM定义了两个   几代人：年轻一代   （有时称为“托儿所”）和   老一辈。年轻人   一代由“伊甸园空间”组成   和两个“幸存者空间”。 VM   最初将所有对象分配给   伊甸园空间，大多数物体死亡   那里。当它执行次要GC时，   VM移动任何剩余的对象   从伊甸园空间到其中一个   幸存者空间。 VM移动对象   在幸存者中活得足够长   空间到“终身”的空间   老一辈。当终身教职   一代填满，有一个完整的   GC通常要慢很多，因为   它涉及所有活动对象。该   永久的一代拥有所有   虚拟机的反射数据   本身，如类和方法   对象。

看一下MXBeans上的collectionCount属性，对于我的“PS MarkSweep”收集器（管理Old Generation池的收集器），只有当我在详细信息中获得完整的GC时，收集计数才会增加输出。我可能错了，也许在某些情况下，这个收集器也执行了较小的GC，但我需要运行更多测试才能完全确定。 如果有人发现其他内容或者您对此问题有更具体的信息，请告诉我，因为我对它很感兴趣。

Answer 2

它确实...看看名称，例如ParNew，ConcurrentMarkSweep，..等 一些名称用于次要gc，一些用于完整gc，

Answer 3

寻找相同的信息后，在阅读https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html#BABFAFAE for JAVA 8后发现，一些收集器可用于次要/完全GC（例如G1或SerialGC），而其他一些收集器仅用于次要或完全GC。完整的GC（例如ParNewGC，ConcMarkSweepGC）。

例如，当您使用G1时，所使用的两个收集器的名称非常明确，而完整gc的收集器则是G1老一代。

但是，由于MXBean缺少有关次要或已满的信息，因此：

• 您知道应用程序使用的GC，并相应地编写监控方法，知道收集器名称
• 或者您开始​​像选择的JVM版本一样拥有所有可能性的地图

就我而言，我只打印收集器名称以及时间和计数值，然后让读取这些数据的人进行分析。就我而言，数据将以图表形式显示（Grafana）

不确定最新的JDK是否可以改善此问题...