HotSpotガベージ・コレクタをチューニングすると、パフォーマンスに大きな影響を与える可能性があります。 概要は、ガベージ・コレクション・チューニング・ガイドを参照してください。

Javaアプリケーションのガベージ・コレクションの問題は、JFRを使用して診断できます。 まず、アプリケーションが起動し実行中であるとき、そのプロファイリング・フライト記録を取ります。 ヒープ統計を含めると、追加のOldコレクションがトリガーされるので、ヒープ統計を含めないでください。 良いサンプルを得るには、より長い記録を取ります(たとえば1時間)。

「メモリー」タブ、「GC回数」サブタブの順に選択します。 「GC回数」は、GCの全体的なパフォーマンスへの影響を調査するために最適なタブです。 右上の「すべてのコレクションの一時休止時間」セクションを参照し、記録からの「平均の一時休止合計」、「最大の一時休止合計」および「合計一時休止時間」を見てください。 「休止の合計」は、GC中にアプリケーションが一時休止した時間の合計です。 多くのGCは、バックグラウンドでほとんどの処理を行います。 この場合、GCの長さは重要ではなく、アプリケーションが実際に停止していた時間が重要です。 したがって、「休止の合計は、GCの影響を適切に測定します。

図4-3は、5分間のフライト記録を示しています(時間選択バーに表示されたとおり)。 この間の「平均の一時休止合計」は16ms、「最大の一時休止合計」は49ms、および「合計一時休止時間」は2s 86msでした。

ガベージ・コレクションの主なパフォーマンスの問題は、通常、個々のGCの時間がかかりすぎるか、GCの一時休止(GCの一時休止の合計)に多くの時間を費やしているかのいずれかです。

個々のGCに時間がかかりすぎる場合は、GCの戦略を変更する必要があります。 一時休止の回数とスループット・パフォーマンスの対比となると、各GCには異なるトレードオフがあります。 詳細は、動作ベースのチューニングの項を参照してください。

たとえば、ファイナライザまたは準参照(あるいはその両方)の使用を減らすように、アプリケーションの修正が必要になる場合もあります。 ファイナライズからの移行の詳細は、「Java Platform, Standard Edition HotSpot仮想マシン・ガベージ・コレクション・チューニング・ガイド」の「ファイナライズおよび弱い参照、ソフト参照およびファントム参照」を参照してください。

アプリケーションが一時休止している時間が多すぎる場合は、様々な回避方法があります。

1つの方法は、Javaヒープ・サイズを増加することです。 「ガベージ・コレクション」サブタブを見てアプリケーションが使用するヒープ・サイズを推定し、「Xms」および「Xmx」をより高い値に変更します。 Javaヒープが大きいほど、GC間の時間は長くなります。 Javaアプリケーションにメモリー・リークがあると、GCがますます頻繁になり、最後にはOutOfMemoryErrorがスローされる可能性があるので、注意が必要です。 詳細は、「Javaフライト・レコーダによるメモリー・リークのデバッグ」を参照してください。

GCの数を減らすもう一つの方法は、より少ない一時オブジェクトを割り当てることです。 「割当て」タブの下で、記録の過程で割り当てられているメモリ量を見てください。 小さなオブジェクトは「TLAB」内に割り当てられ、大きなオブジェクトは「TLAB」外に割り当てられています。 多くの場合、割当ての大半は「TLAB」内で起こります。

最後になりますが、決して軽視できない、必要なGCを低減するための方法は、割当て率を減らすことです。 「新しいTLABの割当て」タブ、「割当て」タブの順に選択して、最も多くのメモリー圧縮を有する割当てサイトおよびスタック・トレースを調べます。 クラスごとにそれを表示するか、「スレッドによる割当て」を選択してほとんどの割当てを消費しているスレッドを確認することもできます。

JFRの「割当て」タブの一般的な詳細は、「フライト記録の検査」を参照してください。

これ以外のいくつかの設定により、JavaアプリケーションのGCのパフォーマンスが向上することもあります。 ガベージ・コレクション・チューニング・ガイドでは、少数を除くほぼすべての章で、GCパフォーマンスについて説明しています。