garbage-collection - 是否可以在JMX中(在HotSpot上)监视 "Full GC"频率？

Question

我想监视JMX中的完整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和完整gc。

有人有主意吗？

谢谢。

阿诺特

Answer 1

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

PS MarkSweep

MemoryPool名称:PS Eden Space，PS Survivor Space，PS Old Gen，PS Perm Gen

CollectionCount:68

PS清道夫

MemoryPool名称:PS Eden Space，PS Survivor Space

CollectionCount:2690

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

更新(基于@ajeanson评论，感谢您的反馈，顺便说一句):

实际上，我放入的示例来自我所使用的JVM的MXBean中公开的信息。如您所提到的，这些是GC算法，并且GC使用的MXBean的名称是基于GC使用的算法的。我一直在寻找有关此的更多信息。在本文http://download.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html中，读取以下内容:

The Java HotSpot VM defines two generations: the young generation (sometimes called the "nursery") and the old generation. The young generation consists of an "Eden space" and two "survivor spaces." The VM initially assigns all objects to the Eden space, and most objects die there. When it performs a minor GC, the VM moves any remaining objects from the Eden space to one of the survivor spaces. The VM moves objects that live long enough in the survivor spaces to the "tenured" space in the old generation. When the tenured generation fills up, there is a full GC that is often much slower because it involves all live objects. The permanent generation holds all the reflective data of the virtual machine itself, such as class and method objects.

看一下MXBean上的collectionCount属性，以我的“PS MarkSweep”收集器(管理旧版池的收集器)为例，收集计数似乎仅在我在详细输出中获得完整的GC时才增加。我可能是错的，也许在某些情况下，该收集器还会执行次要的GC，但是我需要运行更多的测试才能完全确定这一点。
请让我知道是否有人发现其他问题，或者您对这个问题有更具体的信息，因为我对此很感兴趣。