QuarkusのGCチューニング入門！Javaアプリのパフォーマンスを最適化する基本技術

1. Quarkusにおけるガベージコレクションの役割

1. Quarkusにおけるガベージコレクションの役割

Java仮想マシン（JVM）上で動作するQuarkusアプリケーションにとって、ガベージコレクション（GC）は「使い終わったメモリを自動的に回収する仕組み」です。開発者が手動でメモリを解放する必要がないため非常に便利ですが、GCが実行されている間はアプリケーションの処理が一時的に止まる「Stop The World（STW）」という現象が発生します。

クラウドネイティブな環境やマイクロサービスでは、レスポンスタイムの短縮が求められます。GCの頻度が多かったり、一回の回収に時間がかかりすぎたりすると、システム全体のパフォーマンスが低下してしまいます。そのため、Quarkusのポテンシャルを最大限に引き出すためには、適切なGCアルゴリズムの選択とパラメータ調整が欠かせません。

2. JVMモードでのGCアルゴリズムの選択肢

2. JVMモードでのGCアルゴリズムの選択肢

Quarkusを標準的なJVMモードで実行する場合、使用するJDKのバージョンによってデフォルトのGCアルゴリズムが異なります。一般的には以下の三つのアルゴリズムがよく検討されます。

• G1GC (Garbage First Garbage Collector): Java 9以降のデフォルトです。大容量メモリでも停止時間を予測可能に抑える設計になっています。
• ZGC (Z Garbage Collector): 超低遅延を目的としたGCで、テラバイト級のメモリでも停止時間をミリ秒以下に抑えることができます。
• Shenandoah GC: ZGCと同様に低遅延を目指したアルゴリズムで、Red Hat社が主導して開発しているため、Quarkusとの相性も抜群です。

以下のコードは、Quarkusを起動する際に特定のGCアルゴリズムを指定する例です。

// 起動時に環境変数や引数でGCを指定するイメージ
// 実際にはDockerfileやjava -jarコマンドの引数として渡します
public class GcConfigExample {
    public static void main(String[] args) {
        System.out.println("Applying Shenandoah GC for Low Latency...");
        // 実行時の引数例: -XX:+UseShenandoahGC
    }
}

3. コンテナ環境でのメモリ制限とHeapSizeの設定

3. コンテナ環境でのメモリ制限とHeapSizeの設定

QuarkusはDockerやKubernetesなどのコンテナ環境で動かすことが一般的です。コンテナにはメモリ制限（Limit）がありますが、JVMがその制限を正しく認識できないと、コンテナが強制終了（OOM Kill）されてしまうことがあります。

Quarkusでは、application.propertiesに設定を書くのではなく、JVMの起動オプションでヒープサイズを制御するのが基本です。特に、コンテナのメモリ使用率に合わせて動的にヒープサイズを決定する設定が推奨されます。

// メモリ使用量を制限するためのオプション設定例
public class MemoryLimitSettings {
    public static void main(String[] args) {
        // コンテナのメモリの50%をヒープに割り当てる設定
        // 引数例: -XX:MaxRAMPercentage=50.0
        System.out.println("Max Heap is set to 50% of Container Memory.");
    }
}

4. ネイティブイメージにおけるGCの仕組み

4. ネイティブイメージにおけるGCの仕組み

Quarkusの最大の特徴である「Native Executable（ネイティブ実行ファイル）」では、通常のJVMとは異なる「GraalVM Native Image GC」が動作します。デフォルトではSerial GCという、非常にシンプルで省メモリなアルゴリズムが採用されています。

Serial GCは単一スレッドで動作するため、メモリ消費量は極めて少ないですが、スループットが高いアプリケーションではボトルネックになる可能性があります。企業向けの商用版（MandrelやGraalVM Enterprise）では、ネイティブイメージでもG1GCを使用することが可能です。

ネイティブビルド時にGCを指定する場合は、ビルドオプションに追加します。以下はMavenプロジェクトでの設定イメージです。

<!-- pom.xmlのプロパティ設定例 -->
<properties>
    <quarkus.native.additional-build-args>
        --gc=G1
    </quarkus.native.additional-build-args>
</properties>

5. オブジェクトの生存期間を意識したコーディング

5. オブジェクトの生存期間を意識したコーディング

チューニングにおいて最も効果的なのは、実は「GCに仕事をさせないこと」です。不要なオブジェクト生成を減らすことで、GCの頻度を劇的に下げることができます。特に、文字列結合を繰り返す処理や、大きなコレクションのコピーには注意が必要です。

Quarkusの依存注入（CDI）を利用する際も、スコープを適切に設定しましょう。例えば、状態を持たないサービスであれば@ApplicationScopedを使うことで、リクエストごとにインスタンスが生成されるのを防ぐことができます。

import jakarta.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class PerformanceService {
    public String processData(String input) {
        // StringBuilderを使用してメモリ効率を高める
        StringBuilder sb = new StringBuilder();
        sb.append("Processed: ").append(input);
        return sb.toString();
    }
}

6. メモリリークを防ぐためのモニタリング手法

6. メモリリークを防ぐためのモニタリング手法

どれだけGC設定を煮詰めても、アプリケーションコードにメモリリークがあれば、いずれシステムはダウンします。Quarkusには標準でMicrometer Metricsという拡張機能があり、これを利用することでリアルタイムにヒープの使用状況を監視できます。

PrometheusやGrafanaと組み合わせることで、GCの実行回数や停止時間を可視化し、異常なメモリ消費の予兆をいち早く察知することが可能になります。開発段階からメトリクスを確認する癖をつけることが、高いパフォーマンスを維持するコツです。

# Micrometerが出力するメトリクスの例
jvm_memory_used_bytes{area="heap",id="G1 Old Gen"} 125829120
jvm_gc_pause_seconds_count 42
jvm_gc_pause_seconds_sum 0.845

7. Quarkus特有のビルド時最適化の恩恵

7. Quarkus特有のビルド時最適化の恩恵

Quarkusが他のJavaフレームワークより高速な理由の一つに、ビルド時にメタデータの解析を済ませてしまう「Build Time Boot」があります。これにより、実行時のクラスロードやリフレクションが大幅に削減されます。

これはGCにも好影響を与えます。起動時に生成される一時的なオブジェクトが少なくなるため、アプリケーションが安定状態（ウォームアップ完了後）に移行するまでの時間が短縮されます。私たちは、フレームワークが提供するこの仕組みを壊さないよう、極力軽量なライブラリ選定を心がけるべきです。

8. パフォーマンス検証のための負荷テストの重要性

8. パフォーマンス検証のための負荷テストの重要性

最後のステップは、実際の環境を模した負荷テストです。理論上の設定が常に最適とは限りません。JMeterやGatlingといったツールを使用して、秒間リクエスト数を増やしたときにGCがどのように振る舞うかを確認します。

特に、ヒープメモリがいっぱいになったときに発生する「Full GC」が発生していないかをチェックしてください。もし頻発しているようであれば、ヒープサイズの増量か、アルゴリズムの再選定、あるいはコード内での大きなオブジェクト生成の見直しが必要です。実測値に基づいたチューニングこそが、最も信頼できるパフォーマンス向上策となります。