KubernetesのJavaガベージコレクション：最適なコレクタの選定とサイジング

TL;DR

• デフォルト： Kubernetes上のほとんどのJavaサービスでは、G1が最初に選ぶべきコレクタです。
• 境界値： JVMがG1を選択するのは、CPUが2以上かつメモリが1792 MB以上の場合のみ。それ未満では、何の通知もなくSerialが選択されます。
• 明示的に指定する： CPUやメモリ制限の変更でコレクタが切り替わらないよう、フラグで固定しましょう。
• Podサイズで選ぶ： 一般的なサービスにはG1、バッチにはParallel、CPUとメモリに余裕があるレイテンシ重視のサービスにはZGCまたはShenandoah。
• メモリ： ヒープはプロセスの一部にすぎません。-Xmxの外側に余裕を確保しておかないと、ヒープが満杯でなくてもPodはOOMKilledになります。

Kubernetes上のほとんどのJavaサービスにとって、G1は適切なガベージコレクタです。ただし、JVMが自動的にG1を選択するのは、Podに2以上のCPUと約1.75 GBのメモリがある場合に限られます。それ未満では、JVMは何の通知もなくSerialコレクタにフォールバックします。つまり、CPU制限のわずかな変更がサービスのガベージコレクション方式を変えてしまう可能性があり、その際に誰にもアラートは届きません。

本記事では、Javaのガベージコレクションの役割、JVMがコンテナの制限値からコレクタを選択する仕組み、G1・ZGC・Shenandoah・Parallel・Serialの違い、そしてPodサイズごとにどれを使うべきかを解説します。また、現在のJVMの動作を確認する方法や、GC設定がOOMKilledやCPUスロットリングとどう関係するかも紹介します。

JavaのPodが起動時に再起動やスロットリングを起こしている場合は、まずJVM起動時のCPUスロットリングをお読みください。本記事では同じ問題の定常状態側を扱います。

実際の動作を見てみたい方は、2026年10月28日 午前11時（米国東部時間）開催のハンズオンワークショップJava on K8s: The Startup vs. Steady-State Sizing Dilemmaにぜひご参加ください。

JVMのガベージコレクタの動作を確認するには？

確認すべきは3つです。どのコレクタが動いているか、GCのコストはどれくらいか、そしてコンテナがスロットリングされているか。

JVMが選択したコレクタとCPU数

kubectl exec <pod-name> -- jcmd 1 VM.flags -all \
  | grep -E 'UseSerialGC|UseG1GC|UseZGC|UseParallelGC|ParallelGCThreads|ConcGCThreads'

これには、イメージにjcmdが含まれていること、JVMがプロセス1として動作していることが必要です。JREのみのイメージにはjcmdは含まれません。

GCログ

環境変数で統合GCロギングを有効にし、一時停止の行を確認します。

env:
  - name: JAVA_TOOL_OPTIONS
    value: "-Xlog:gc*:stdout:time,uptime"

Youngコレクションの頻度、一時停止の長さ、Fullコレクションの有無を確認しましょう。Fullコレクションが頻発している場合、ヒープがライブデータに対して小さすぎます。

アラートを設定すべきメトリクス

MicrometerやPrometheus JMX exporterを使っている場合、以下のメトリクスでGCコストの推移を把握できます。

ヒープとコンテナメモリの行はあわせて確認しましょう。ヒープが制限を大きく下回っているのにワーキングセットが制限に近い場合、原因はコレクタではなく非ヒープメモリです。GC中のスロットリング割合が高い場合は、選択したコレクタに対してCPU制限がきつすぎることを示しています。

GCとCPUの負荷は、多くの場合Pod起動直後の数秒間にピークを迎え、その後5分間隔のダッシュボードからは消えてしまいます。これを捕捉する方法はKubernetesの起動時スパイクを検出する方法をご覧ください。

ガベージコレクションをコンテナ対応にするJVMフラグは？

JVMはデフォルトでコンテナの制限値を読み取ります（-XX:+UseContainerSupport）。以下のフラグを使えば、その結果を明示的かつ再現可能にできます。

2 CPU・2 GiBメモリの一般的なAPI Podの初期設定は、次のようになります。

env:
  - name: JAVA_TOOL_OPTIONS
    value: >-
      -XX:+UseG1GC
      -XX:MaxRAMPercentage=65
      -XX:+ExitOnOutOfMemoryError
      -Xlog:gc*:stdout:time,uptime

65という値は出発点であり、すべてのサービスへの推奨値ではありません。まず非ヒープのフットプリントを計測し、その後調整してください。古いブログ記事から大量のチューニングフラグをコピーするのは避けましょう。デフォルト値はJDKバージョンによって変わっており、余分なフラグはGCの挙動をかえって分かりにくくすることが多いためです。

PerfectScaleによるJava workloadsのライトサイジング

GC設定、ヒープサイズ、Podのリクエストと制限は互いに影響し合います。他を考慮せずに1つだけ変更すると、スロットリングされたPodやOOMKilledによる再起動につながります。PerfectScaleはこれらのシグナルをまとめて表示します。

Javaコンテナ向けに、PerfectScaleはヒープ、非ヒープ、ガベージコレクションのデータを収集します。GC時間、アクティブプロセッサ数、GCタイプが表示されるため、各workloadがどのコレクタを使い、どれだけのコストがかかっているかを把握できます。JVMメトリクスの収集は、PerfectScaleエージェントのインストール時に有効化できます。対応はLinuxノードのみです。

また、PerfectScaleはお客様のJVM設定を尊重します。最大または最小ヒープサイズを設定している場合、PerfectScaleはその範囲を超える推奨を適用しません。再起動なしでPodをリサイズする方法は、インプレースのライトサイジングとVertical Pod Autoscalerをご覧ください。

ワークショップ：Java on K8s: The Startup vs. Steady-State Sizing Dilemma。 DoiTのVikram Seshadriが、JVM起動時のスパイク、それがスロットリング・OOM kill・過剰なリクエスト設定にもたらすコスト、そして再起動なしのインプレースリサイズで定常状態向けにPodをサイジングする方法を解説します。2026年10月28日 午前11時（米国東部時間）開催。今すぐ席を確保。

PerfectScaleによるJava workloadsのライトサイジングを、実際に見てみませんか？無料で始めるまたはデモを予約するからどうぞ。

FAQ

Javaのデフォルトのガベージコレクタは何ですか？ サーバークラスのマシン、つまりプロセッサが2以上かつメモリが1792 MB以上の場合はG1です。それ以外ではJVMはSerialを選択します。コンテナでは、JVMはCPU制限とメモリ制限を読み取って判断します。

Javaで最良のガベージコレクタはどれですか？ あらゆる場面で勝るコレクタはありません。ほとんどのサービスにはG1が最良の出発点です。バッチ処理にはParallelが、CPUとメモリに余裕のあるレイテンシ重視のサービスにはZGCまたはShenandoahが適しています。

Javaは自動でガベージコレクションを行いますか？ はい。JVMは開発者の呼び出しなしに、未使用のオブジェクトを見つけてメモリを解放します。コレクタの選択、ヒープサイズ、GCフラグでチューニングできます。

Javaのガベージコレクションはどのように動作しますか？ コレクタは、アプリケーションから到達できなくなったオブジェクトを見つけてメモリを解放し、多くの場合、残ったものをコンパクションします。ほとんどのオブジェクトは短命であるため、大半のコレクタはヒープをYoung世代とOld世代に分けています。

ZGCはG1より優れていますか？ ZGCはより短い一時停止を目指しており、その代償としてCPUとメモリを多く消費します。CPUに余裕のある大きめのヒープで最も効果を発揮する傾向があります。小さいPodでは、通常G1の方が安全な選択です。実際のトラフィックでテストしてください。

ヒープが満杯でないのに、JavaのPodがOOMKilledになるのはなぜですか？ コンテナの制限は、ヒープに加えてメタスペース、スレッドスタック、コードキャッシュ、ダイレクトバッファ、コレクタの構造体も対象とします。-Xmxの外側に余裕を確保し、ヒープ使用量とコンテナのワーキングセットを比較してください。

CPU制限はJavaのガベージコレクションに影響しますか？ はい、2つの点で影響します。制限値は、JVMがGCスレッド数を決めるためのCPU数を定め、メモリと合わせてコレクタの選択にも使われます。また、GCスレッドとアプリケーションスレッドが共有するCPUの上限にもなるため、スロットリングが発生すると両者が停止します。

関連記事

• 2026年にJavaを最適化する5つの戦略：コンテナを意識したヒープ・CPU・GC設定
• JVM起動時のCPUスロットリング：JVMが起動直後の数秒間に最も多くのCPUを必要とする理由
• Kubernetesの起動時スパイクを検出する：ダッシュボードが隠すスロットリングとOOM killを見つける
• 誤ったフェーズに最適化されたKubernetesリソースポリシーを修正する：起動時と定常状態のためのクォータとLimitRange
• KubernetesのOOMKilledを解決する方法
• Kubernetes CPUスロットリング
• KubernetesのCPU制限
• Kubernetesのリソース制限とリクエストの違い
• 再起動なしでPodをリサイズできる！本当に？
• Kubernetes Vertical Pod Autoscaler（VPA）
• Kubernetes Horizontal Pod Autoscaler（HPA）