jmxからGarbageCollectionMXBeanを取得できました。しかし、どのように区別できるかメジャー gc フル gc？それは非公式の言葉です。古い世代が掃除された場合、私はのメジャーとしてgcを示します。そして、完全な私はgcコンパクト（デフラグ）ヒープを意味します。実用的な観点からは、同時モードが失敗するかプログラマが明示的に呼び出すときに完全なgcが発生するSystem.gsjmxでgcコンパクト化を監視することはできますか？
このようなイベントをjmxで区別することは可能ですか？警告の
二つの言葉：「主要な」GC、あなたはそれを定義するように、必ずしも圧縮を排除するものではない（例えばG1GCが主要なサイクルに増分圧縮を実行）することを
AFAIKでは、圧縮および非圧縮イベントについてJMX Beanで提供されるデータはありません。 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 docs（java8）：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html - クイックリファレンス。ほとんどのコレクター（しかし、古い）https://blogs.oracle.com/jonthecollector/our-collectors の - 異なるJVM実装の一例としてジングの連続圧縮コレクター：//gist.github：http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf
JMXを通じてGC原因を取得することが可能である、[例]（HTTPSを参照してください。 com/apangin/85a8386d22fa8bcc89a2ed8120f8b77d）。通常、CMSサイクルには「GCなし」*原因があります。明示的GCには* "System.gc" *原因があり、同時モードの失敗は通常 "* ConcurrentMarkSweep - Allocation Failure" *の原因となります。これで十分か、他の何かを探していますか？ – apangin
かなり近いです。実際、私はこの通知の説明を見つけて、サンプルエージェントを作成して統計を収集し、 "gcAction"、 "gcCause"、およびgcの動作の間に相関関係を見つけることに忙しかった。 – ayvango