サンプルコードで身につける: 起動を速くする方向と失うもの

解説で学んだ概念を、5つの具体例で確認します。素朴な例から実務寄りの例へと進みます。

1同じアプリを4通りの形で起動する

のまま、置き方と事前の準備だけを変えた実測です(ready はプロセスの起動直前から GET /hello の応答を読み終えるまで)。起動は段階ごとに短くなりましたが、はを使っても減っていません。下のはの再起動をはさんだ別の系列なので、表を分けてあります。

起動時間とアイドル時 RSS(各7回の範囲。Boot 4.1.1 / JDK 25。メモリ上限なし・JVM オプション既定)表

再起動前の系列
形態                                      Started in(秒)   ready(ms)   アイドル RSS(MB)
fat JAR(java -jar demo.jar)             0.599〜0.637       814〜844      266〜285
展開(java -jar application/demo.jar)    0.534〜0.551       695〜716      265〜287
展開 + CDS                                0.354〜0.370       468〜492      264〜306
展開 + AOT キャッシュ                     0.252〜0.259       366〜441      288〜304
 
再起動後の系列(-Pnative でビルドした JAR を JVM で -Dspring.aot.enabled=true)
形態                                      Started in(秒)   ready(ms)   アイドル RSS(MB)
展開(取り直し)                         0.530〜0.642       691〜804      268〜287
展開 + AOT キャッシュ(取り直し)        0.247〜0.445       359〜584      280〜298
展開 + Spring AOT                         0.423〜0.460       570〜610      251〜260
展開 + Spring AOT + AOT キャッシュ        0.176〜0.204       278〜377      229〜243

2fat JAR のまま AOT キャッシュを指定したときの警告

展開せずにへを付けて起動したときに JVM が出した行です。キャッシュを作ったときとが合わないと言って、キャッシュ無しで起動しました(起動時間は 0.610〜0.639 秒で、付けないときの 0.599〜0.637 秒とほぼ同じです)。リファレンスにも「You have to use the cache file with the extracted form of the application, otherwise it has no effect.」とあります。

fat JAR のまま -XX:AOTCache を付けて起動したときの JVM の出力(先頭4行。JDK 25)追跡ログ

[0.014s][warning][aot] This file is not the one used while building the AOT cache: 'demo.jar', size has changed
[0.014s][error  ][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details.
[0.014s][error  ][aot] shared class paths mismatch (hint: enable -Xlog:class+path=info to diagnose the failure)
[0.015s][error  ][aot] Unable to map shared spaces
...

3素の Java で見る: 名前で呼ぶクラスはソースを読んでも分からない

は、アプリを動かさずにコードを解析して、要るだけを実行ファイルに入れます。ところが下の2つ目の呼び出しのように、クラス名を実行時に組み立ててで呼ぶと、ソースを読むだけではどのクラスが要るか決まりません。Spring AOT はの生成を HelloController::new のような普通のコードに置き換え、それでも残るリフレクションの対象は一覧にして渡します。

Java

import java.lang.reflect.Method;

class Greeter {
    public String hello() { return "hello from Greeter"; }
}

// Main のソースには、このクラスを型として使う行が1つも無い
class Hidden {
    public String hello() { return "hello from Hidden"; }
}

class Main {
    static String callByName(String className) {
        try {
            Class<?> type = Class.forName(className);          // 名前の文字列からクラスを探す
            Object target = type.getDeclaredConstructor().newInstance();
            Method m = type.getMethod("hello");
            return (String) m.invoke(target);
        } catch (ReflectiveOperationException e) {
            return e.getClass().getSimpleName() + ": " + e.getMessage();
        }
    }

    public static void main(String[] args) {
        // 1) ソースに型名が書いてある呼び出し。ソースを読むだけで Greeter が要ると分かる
        System.out.println("direct : " + new Greeter().hello());

        // 2) 名前を実行時に組み立てる呼び出し。ソースを読むだけでは、どのクラスが要るか決まらない
        String name = new StringBuilder("neddiH").reverse().toString();
        System.out.println("by name: " + name + " -> " + callByName(name));

        // 3) その名前のクラスが無ければ、実行してはじめて分かる
        System.out.println("by name: Missing -> " + callByName("Missing"));
    }
}

// 出力(JVM 上での実行結果)
// direct : hello from Greeter
// by name: Hidden -> hello from Hidden
// by name: Missing -> ClassNotFoundException: Missing

import java.lang.reflect.Method;

class Greeter {
    public String hello() { return "hello from Greeter"; }
}

// Main のソースには、このクラスを型として使う行が1つも無い
class Hidden {
    public String hello() { return "hello from Hidden"; }
}

class Main {
    static String callByName(String className) {
        try {
            Class<?> type = Class.forName(className);          // 名前の文字列からクラスを探す
            Object target = type.getDeclaredConstructor().newInstance();
            Method m = type.getMethod("hello");
            return (String) m.invoke(target);
        } catch (ReflectiveOperationException e) {
            return e.getClass().getSimpleName() + ": " + e.getMessage();
        }
    }

public static void main(String[] args) {
        // 1) ソースに型名が書いてある呼び出し。ソースを読むだけで Greeter が要ると分かる
        System.out.println("direct : " + new Greeter().hello());

// 2) 名前を実行時に組み立てる呼び出し。ソースを読むだけでは、どのクラスが要るか決まらない
        String name = new StringBuilder("neddiH").reverse().toString();
        System.out.println("by name: " + name + " -> " + callByName(name));

// 3) その名前のクラスが無ければ、実行してはじめて分かる
        System.out.println("by name: Missing -> " + callByName("Missing"));
    }
}

// 出力(JVM 上での実行結果)
// direct : hello from Greeter
// by name: Hidden -> hello from Hidden
// by name: Missing -> ClassNotFoundException: Missing

4Spring AOT が出力した申告の一覧

がビルド時に生成したの冒頭です(全体は 147,945 バイト)。リフレクションで触るクラスを1つずつ並べて、native image の解析に伝えています。なお 4.1 のリファレンスは reflect-config.json など複数のファイル名を挙げていますが、4.1.1 が実際に生成したのはこの1本と native-image.properties でした。

target/spring-aot/main/resources/META-INF/native-image/com.example/demo/reachability-metadata.json(冒頭)設定ファイル

{
  "comment": "Spring Framework 7.0.9",
  "reflection": [
    {
      "type": "ch.qos.logback.classic.LoggerContext"
    },
    {
      "type": "ch.qos.logback.classic.pattern.SyslogStartConverter",
      "allPublicConstructors": true
    },
...

5native image のビルドログ: 1分あまりと約4GBの中身

のログのうち、が出した部分の抜粋です。hello を返すだけのアプリで、到達できると判定された型が 18,730、リフレクション用に登録された型が 7,026 ありました。この回のピークのメモリは 4.18GB で、同じプロジェクトのは 2.3 秒でした。

./mvnw -B -Pnative native:compile の2回目(GraalVM CE 25.0.2 / arm64。壁時計とピークは1回目 66.2 秒・4.29GB、2回目 68.3 秒・4.18GB)コマンド出力