レコードクラスの中身

本エントリーはJava Advent Calendar 2025の最終日です！ 昨日は@zoosm3さんのDBFluteの複数DBをSpring Bootで実装する 開発のヒント でした。

 

24日に会社ブログでレコードクラスについて書きました。けっこうまじめに書いたので、ぜひ読んでみてください！

[Java] 今から始めるレコードクラス
https://bsblog.casareal.co.jp/archives/13817

レコードクラスの書き方や使い方については書きましたけど、じゃあレコードクラスって実際にはどういうバイトコードになっているの？？というのが本エントリーです。

レコードクラスは簡単な記述で済んでいるのですが、コンパイルするとアクセッサーメソッドやequalsメソッドが自動生成されますとよく書かれていますが(会社ブログでもそう書きました)、実際のところどうなっているのというのを紹介していきます。

 

とりあえず、逆コンパイル

では、レコードクラスのバイトコードがどうなっているのか、さっそく調べてみましょう。題材にするのは、よく出てくる座標を表すPointレコードクラスです。

 

public record Point(double x, double y) {}

 

このクラスをコンパイルした後に、javapで逆コンパイルします。

 

> javac -g Point.java
> javap -p -v Point
Classfile /C:/temp/Point.class
  Last modified 2025/12/21; size 1348 bytes
  SHA-256 checksum 4bcbbc4b22a7b6c6fb72067dba973f9f08f80def796ecca1173c7c3b6596bda4
    Compiled from "Point.java"
public final class Point extends java.lang.Record
     ... 以下、略

 

javapのオプションの-pはprivateも逆コンパイルするというオプションで、-vは詳細情報を出力するオプションです。

この後にコンスタントプールが続くのですが、とりあえず重要なところで

 

public final class Point extends java.lang.Record

 

レコードクラスは継承ができないのですが、この行が理由です。

まず、java.lang.Recordクラスのサブクラスになるということ。そして、finalクラスだということです。

Recordクラスは以下の3種類の抽象メソッドを定義しています。

• equals
• hashCode
• toString

もちろん、この3つのメソッドはObjectクラスで具象メソッドとして定義されているのですが、Recordクラスではそれらを抽象クラスとしてオーバーライドしています。

つまり、Ojbectクラスの実装は使わないということですね。

しかし、recordキーワードで定義されるレコードクラスは、これらのメソッドを定義する必要がありません。これらのメソッドがコンパイル時に自動生成されるというのが、このことからも分かります。

 

レコードコンポーネント

javapでは、クラス定義の後にコンスタントプールを出力します。コンスタントプールは必要に応じて参照すればよいので、その後に続く部分を見てみましょう。

通常のクラスであればフィールドの定義が続きます。レコードクラスではどうでしょう？

 

  private final double x;
    descriptor: D
    flags: (0x0012) ACC_PRIVATE, ACC_FINAL

  private final double y;
    descriptor: D
    flags: (0x0012) ACC_PRIVATE, ACC_FINAL

 

名前だけはレコードコンポーネントになりましたが、実質的にはインスタンスフィールドと同じでした。まぁ、想像通りですね。

イミュータブルなので、finalで宣言されているところが注目すべき点です。

 

コンストラクター

レコードクラスではカノニカルコンストラクターが自動的に生成されます。と言われても、カノニカルって何？という感じですよね。

カノニカル(Canonical)は「正規の」とか「標準的な」などの意味の単語です。このため、カノニカルコンストラクターを標準コンストラクターと記述しているドキュメントもあります。でも、標準と書かれるとStandardの方をイメージしてしまうんですよね。

ネイティブの人たちはCanonicalとStandardのニュアンスの違いを分かっているのでしょうが、私には理解できないのです...

 

それはそれとして、カノニカルコンストラクターはすべてのレコードコンポーネントを初期化するためのコンストラクターです。

では、Pointレコードクラスのカノニカルコンストラクターを見てみましょう。

 

  public Point(double, double);
    descriptor: (DD)V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=3, locals=5, args_size=3
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Record."<init>":()V
         4: aload_0
         5: dload_1
         6: putfield      #7                  // Field x:D
         9: aload_0
        10: dload_3
        11: putfield      #13                 // Field y:D
        14: return
      LineNumberTable:
        line 1: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      15     0  this   LPoint;
            0      15     1     x   D
            0      15     3     y   D
    MethodParameters:
      Name                           Flags
      x
      y

 

カノニカルコンストラクターの引数は、レコードクラスの定義におけるレコードコンポーネントの並びに対応しています。

Pointレコードクラスの場合、両方ともdoubleなので区別しにくいですが、第1引数がx、第2引数がyです。

 

一般的にコンストラクターのバイトコードでは、まずスーパークラスのデフォルトコンストラクターをコールします。それが0行目と1行目のinvokespecialです(行と書いていますが、実際にバイト数のことです。あしからず)。

4行目のaloadからがレコードコンポーネントの初期化になります。6行目のputfieldで引数のxの値をフィールドにセットしています。

同様に、11行目のputfieldで引数のyの値をフィールドにセットしています。

単純に引数の値をフィールド(レコードコンポーネント)に代入しているだけですね。

 

カノニカルコンストラクターは独自に定義することもできるのですが、それについては後述します。

 

アクセッサーメソッド

レコードクラスではレコードコンポーネントと同名のメソッドが生成され、レコードコンポーネントの値を取得できます。

まぁ、名前は違うもののgetterメソッドと同じですね。Pointレコードクラスのx()メソッドのバイトコードは以下のようになっていました。

 

  public double x();
    descriptor: ()D
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=1, args_size=1
         0: aload_0
         1: getfield      #7                  // Field x:D
         4: dreturn
      LineNumberTable:
        line 1: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   LPoint;

 

getfieldでフィールド(レコードコンポーネント)の値をスタックに積んで、dreturn (doubleのretuen)で返り値にしています。

y()メソッドも同様です。

 

他の自動生成されたメソッド

ここまでは、まぁ予想通りのバイトコードでした。

レコードクラスではカノニカルコンストラクターとアクセッサーメソッド以外に、次のメソッドを自動生成します。

• equals
• hashCode
• toString

ここではequals()メソッドのバイトコードを見てみましょう。

equals()メソッドの書き方としては、Effective Javaが詳しいですね。Effective Javaの書き方と比べてどうなっているでしょう？

 

  public final boolean equals(java.lang.Object);
    descriptor: (Ljava/lang/Object;)Z
    flags: (0x0011) ACC_PUBLIC, ACC_FINAL
    Code:
      stack=2, locals=2, args_size=2
         0: aload_0
         1: aload_1
         2: invokedynamic #24,  0             // InvokeDynamic #0:equals:(LPoint;Ljava/lang/Object;)Z
         7: ireturn
      LineNumberTable:
        line 1: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       8     0  this   LPoint;
            0       8     1     o   Ljava/lang/Object;

 

なんか全然違う！！

おもしろいのは、invokedynamic (indy)を使っているところです。つまり、equals()メソッドは初回実行時に動的に作られるということですね。

このindyの初回実行時にコールされるのが、ブートストラップと呼ばれるメソッドです。ブートストラップメソッドはクラスファイルの最後の方にあるBootstrapMethods:の箇所に記述されています。

 

BootstrapMethods:
  0: #49 REF_invokeStatic java/lang/runtime/ObjectMethods.bootstrap:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/TypeDescriptor;Ljava/lang/Class;Ljava/lang/String;[Ljava/lang/invoke/MethodHandle;)Ljava/lang/Object;
    Method arguments:
      #8 Point
      #45 x;y
      #47 REF_getField Point.x:D
      #48 REF_getField Point.y:D

 

これを見ると、ブートストラップとして使われるのは、java.lang.runtime.ObjectMethodsクラスのbootstrap()メソッドだということです。実をいうと、equals()メソッドだけでなく、hashCode()メソッドもtoString()メソッドも同じブートストラップメソッドが使われています。

このObjectMethodsクラスはpublicなクラスなので、APIドキュメントが公開されています。Java 24であれば、以下のリンクから参照できます。

ObjectMethodsクラス
https://docs.oracle.com/javase/jp/24/docs/api/java.base/java/lang/runtime/ObjectMethods.html

ちょっとおもしろいのが、bootstrap()メソッドの最後の引数にアクセッサーメソッドのMethodHandleが使われているところですね。

 

では、ObjectMethodsクラスのbootstrap()メソッドを調べてみましょう。ソースは以下のリンクにあります。

ObjectMethods
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/runtime/ObjectMethods.java

以下にObjectMethodsクラスのbootstrap()メソッドのソースを示します。

 

    public static Object bootstrap(MethodHandles.Lookup lookup, String methodName, TypeDescriptor type,
                                   Class<?> recordClass,
                                   String names,
                                   MethodHandle... getters) throws Throwable {

            <<省略>>
    
        List<MethodHandle> getterList = List.of(getters);
    
        MethodHandle handle = switch (methodName) {
            case "equals"   -> {
                if (methodType != null && !methodType.equals(MethodType.methodType(boolean.class, recordClass, Object.class)))
                    throw new IllegalArgumentException("Bad method type: " + methodType);

                yield makeEquals(lookup, recordClass, getterList);
            }

              <<省略>>
        };
 
        return methodType != null ? new ConstantCallSite(handle) : handle;
    }

 

メソッド名が"equals"であれば、makeEquals()メソッドをコールしています。

makeEquals()メソッドはClassfile APIでバイトコードを操作しています。ASMの頃に比べると、Classfile APIになって格段に読みやすくなりましたね。

ちょっと長いのですが、makeEquals()メソッドを以下に示しておきます。

 

    private static MethodHandle makeEquals(MethodHandles.Lookup lookup, Class<?> receiverClass,
                                           List<MethodHandle> getters) throws Throwable {
        MethodType rr = MethodType.methodType(boolean.class, receiverClass, receiverClass);
        MethodType ro = MethodType.methodType(boolean.class, receiverClass, Object.class);
        MethodHandle instanceFalse = MethodHandles.dropArguments(FALSE, 0, receiverClass, Object.class); // (RO)Z
        MethodHandle instanceTrue = MethodHandles.dropArguments(TRUE, 0, receiverClass, Object.class); // (RO)Z
        MethodHandle isSameObject = OBJECT_EQ.asType(ro); // (RO)Z
        MethodHandle isInstance = MethodHandles.dropArguments(CLASS_IS_INSTANCE.bindTo(receiverClass), 0, receiverClass); // (RO)Z
        MethodHandle accumulator = MethodHandles.dropArguments(TRUE, 0, receiverClass, receiverClass); // (RR)Z

        int size = getters.size();
        MethodHandle[] equalators = new MethodHandle[size];
        boolean hasPolymorphism = false;
        for (int i = 0; i < size; i++) {
            var getter = getters.get(i);
            var type = getter.type().returnType();
            if (isMonomorphic(type)) {
                equalators[i] = equalator(lookup, type);
            } else {
                hasPolymorphism = true;
            }
        }

        // Currently, hotspot does not support polymorphic inlining.
        // As a result, if we have a MethodHandle to Object.equals,
        // it does not enjoy separate profiles like individual invokevirtuals,
        // and we must spin bytecode to accomplish separate profiling.
        if (hasPolymorphism) {
            String[] names = new String[size];

            var classFileContext = ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(ClassHierarchyResolver.ofClassLoading(lookup)));
            var bytes = classFileContext.build(ClassDesc.of(specializerClassName(lookup.lookupClass(), "Equalator")), clb -> {
                for (int i = 0; i < size; i++) {
                    if (equalators[i] == null) {
                        var name = "equalator".concat(Integer.toString(i));
                        names[i] = name;
                        var type = getters.get(i).type().returnType();
                        boolean isInterface = type.isInterface();
                        var typeDesc = type.describeConstable().orElseThrow();
                        clb.withMethodBody(name, MethodTypeDesc.of(CD_boolean, typeDesc, typeDesc), ACC_STATIC, cob -> {
                            var nonNullPath = cob.newLabel();
                            var fail = cob.newLabel();
                            cob.aload(0)
                               .ifnonnull(nonNullPath)
                               .aload(1)
                               .ifnonnull(fail)
                               .iconst_1() // arg0 null, arg1 null
                               .ireturn()
                               .labelBinding(fail)
                               .iconst_0() // arg0 null, arg1 non-null
                               .ireturn()
                               .labelBinding(nonNullPath)
                               .aload(0) // arg0.equals(arg1) - bytecode subject to customized profiling
                               .aload(1)
                               .invoke(isInterface ? Opcode.INVOKEINTERFACE : Opcode.INVOKEVIRTUAL, typeDesc, "equals", MTD_OBJECT_BOOLEAN, isInterface)
                               .ireturn();
                        });
                    }
                }
            });

            var specializerLookup = lookup.defineHiddenClass(bytes, true, MethodHandles.Lookup.ClassOption.STRONG);

            for (int i = 0; i < size; i++) {
                if (equalators[i] == null) {
                    var type = getters.get(i).type().returnType();
                    equalators[i] = specializerLookup.findStatic(specializerLookup.lookupClass(), names[i], MethodType.methodType(boolean.class, type, type));
                }
            }
        }

        for (int i = 0; i < size; i++) {
            var getter = getters.get(i);
            MethodHandle equalator = equalators[i]; // (TT)Z
            MethodHandle thisFieldEqual = MethodHandles.filterArguments(equalator, 0, getter, getter); // (RR)Z
            accumulator = MethodHandles.guardWithTest(thisFieldEqual, accumulator, instanceFalse.asType(rr));
        }

        return MethodHandles.guardWithTest(isSameObject,
                                           instanceTrue,
                                           MethodHandles.guardWithTest(isInstance, accumulator.asType(ro), instanceFalse));
    }

 

簡単にいうと、まずレコードコンポーネントごとにその型に応じたequals()メソッドを探します。次に、レコードコンポーネントごとにequals()メソッドをコールするメソッドを持つクラスを動的に作成して、そのメソッドのMethodHandleを作っています。

なかなかおもしろいですね。

 

Classfile APIのビルド系のメソッドはバイトコードと対応したメソッド名になっているので、バイトコードを読めればだいたい分かるはずです。

 

というわけで、equals()メソッド、hashCode()メソッド、toString()メソッドは中身が動的に作成されるのでした。

 

カノニカルコンストラクター再び

最後に、もう一度カノニカルコンストラクターについて。

前述したカノニカルコンストラクターは自動生成されたものでしたが、カノニカルコンストラクターは自分で書くこともできます。

たとえば、範囲を示すRangeレコードクラスで下限が上限を超える場合IllegalArgumentException例外をスローするようなカノニカルコンストラクターを記述してみます。

 

public record Range(double min, double max) {
    public Range {
        if (min > max) {
            throw new IllegalArgumentException();
        }
    }
}

 

カノニカルコンストラクターは引数がレコードコンポーネントの宣言部分と同じなので省略した書き方になります。

そして、コンパイルした後のバイトコードが以下になります。

 

  public Range(double, double);
    descriptor: (DD)V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=4, locals=5, args_size=3
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Record."<init>":()V
         4: dload_1
         5: dload_3
         6: dcmpl
         7: ifle          18
        10: new           #7                  // class java/lang/IllegalArgumentException
        13: dup
        14: invokespecial #9                  // Method java/lang/IllegalArgumentException."<init>":()V
        17: athrow
        18: aload_0
        19: dload_1
        20: putfield      #10                 // Field min:D
        23: aload_0
        24: dload_3
        25: putfield      #16                 // Field max:D
        28: return
      LineNumberTable:
        line 2: 0
        line 3: 4
        line 4: 10
        line 2: 18
        line 6: 28
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      29     0  this   LRange;
            0      29     1   min   D
            0      29     3   max   D
      StackMapTable: number_of_entries = 1
        frame_type = 255 /* full_frame */
          offset_delta = 18
          locals = [ class Range, double, double ]
          stack = []
    MethodParameters:
      Name                           Flags
      min                            mandated
      max                            mandated

 

前半にminとmaxの比較を行って、minが大きければ例外をスローする処理が記述されています。18行目からコンストラクターの引数をフィールド(レコードコンポーネント)に代入する処理です。

フィールドに代入する処理から行われると思っていたら、それは最後なんですね。ちょっと意外でした。

 

まとめ

レコードクラスはデータを扱うのに便利なクラスですが、その中身がどうなっているのかを紹介しました。

 

まとめてみると

• レコードクラスはRecordクラスのサブクラスでfinalクラス
• レコードコンポーネントはfinalなインスタンスフィールド
• カノニカルコンストラクターが生成される
• アクセッサーメソッドはgetter相当
• equals(), hashCode(), toString()は実行時に動的に作成
• カノニカルコンストラクターでフィールドへの代入は最後

 

レコードクラス自体は単純ですが、その裏側はなかなかおもしろかったですね。

OpenJDKのソースを読むのはたいへんですが、このぐらいの小さいところから読み始めるというのはいいかもしれません。

Lazy Constant 実装編

本エントリーはJava Advent Calendar 2025の6日目です。

 

一昨日はLazy Constantの使い方を紹介したので、今日はLazy Constantがどうやって実装されているかを紹介していきます。

 

Lazy Constant
https://www.javainthebox.com/2025/12/lazy-constant.html

 

シングルトン

いきなりシングルトンと言われても... という感じだとは思いますが、Lazy Constantの実装を紐解く前に、シングルトンについて考えてみます。

シングルトンはデザインパターンの1つで、インスタンスを1つに制限するためのパターンです。

シングルトンは一種の大域変数になってしまうので、使いすぎるのはよくないですし、最近はほとんど使われなくなったように思います。でも、その実装はLazy Constantにつながるのです。

そもそもシングルトンの実装ってどうなっていたか覚えていらっしゃいますでしょうか？

 

シンプルなシングルトン

まずはシンプルなシングルトンの実装です。

シングルトンは自身のインスタンスをstaticフィールドで1つ保持します。そして、インスタンスを取得するメソッドが初めてコールされた時に、インスタンスを生成します。インスタンスが存在すれば、それを返します。つまり、遅延初期化なのです。

 

public class Singleton {
    private static Singleton instance;

    private Singleton() {}

    public static Singleton get() {
        if (instance == null) {
            instance = new Singleton();
        }

        return instance;
    }
}

 

インスタンスを勝手に作られないように、コンストラクターはprivateで宣言します。

getメソッド(getInstanceメソッドのことも多いですが、ここではgetメソッドにします)では、staticフィールドのinstanceがnullだったら、つまり初期化されていなければSingletonインスタンスを生成します。そして、そのinstanceを返します。

シングルトンにデータを持たせるのであれば、それなりにフィールドなどを定義しますが、インスタンスを1つに限定させるための実装としてはこれでOKです。

しかも、実際にシングルトンのインスタンスを実際に使う時まで、その初期化を遅らせることができます。

しかし、問題もあります。この実装はスレッドセーフではないという点です。シングルスレッドであればいいのですが、マルチスレッドでは使えません。

 

スレッドセーフなシングルトン

スレッドセーフにするにはどうすればよいでしょう？

もっとも単純なのは、getメソッドをsynchronizedにするという方法です。

 

public class Singleton {
    private static Singleton instance;

    private Singleton() {}

    public synchronized static Singleton get() {
        if (instance == null) {
            instance = new Singleton();
        }

        return instance;
    }
}

 

これでマルチスレッドでも動作します。

問題はスケールしないということです。スレッド数が2, 3であればよいのですが、スレッド数が増えるととたんにロック待ちで渋滞してしまいます。

instanceフィールドは初期化した後は参照されるだけなので、本来であれば同期化は必要ありません。問題は未初期化の状態時に複数スレッドからgetメソッドをコールされる場合です。

 

そこで、getメソッドのインスタンス生成のところだけ同期化することを考えてみます。

 

    public static Singleton get() {
        if (instance == null) {
            // NG これはダメな実装
            synchronized(instance) {
                instance = new Singleton();
            }
        }

        return instance;
    }
}

 

しかし、これではダメなのです。

CPUの効率化のために命令を入れ替えたり、キャッシュにinstanceの値が残っていることもあるので、instanceを初期化しているときに複数のスレッドからアクセスされてしまうことがあります。

そこで、出てくるのがダブルチェックロックという方法です。でも、単にダブルチェックロックだけでは、キャッシュ上のinstanceとメモリのinstanceが同期化されているか保証されません。

そこで、instanceフィールドをアトミックに処理されるようにします。

厳密にやるのであればjava.util.concurrent.atomic.AtomicReferenceクラスを使用しますが、volatileでも大丈夫です。

最終的には次のようになります。

 

public class Singleton {
    // volatileで宣言することによりアトミック性を保証する
    private static volatile Singleton instance;

    private Singleton() {}

    public static Singleton get() {
        if (instance == null) {
            synchronized (Singleton.class) {
                // ダブルチェック
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }

        return instance;
    }
}

 

これでマルチスレッドでスケールするスレッドセーフなシングルトンになります。

 

Lazy Constant

シングルトンが理解できたとして、Lazy Constantの実装です。

java.lang.LazyConstantはインタフェースなので、実際の遅延初期化の部分は実装されていません。どこで実装されているかというと、LazyConstantインタフェースのstaticメソッドのofメソッドを見れば分かります。

 

    static <T> LazyConstant<T> of(Supplier<? extends T> computingFunction) {
        Objects.requireNonNull(computingFunction);
        if (computingFunction instanceof LazyConstant<? extends T> lc) {
            return (LazyConstant<T>) lc;
        }
        return LazyConstantImpl.ofLazy(computingFunction);
    }

 

return文のところを見ると、LazyConstantImplクラスというのがあることがわかります。これがLazyConstantインタフェースを実装したコンクリートクラスです。パッケージはjdk.internal.langパッケージで、公開されていないクラスだということが分かります。

 

では、遅延初期化を行うgetメソッドを見る前に、クラスの宣言と関連するフィールド、そしてofLazyメソッドを見ておきましょう。この他にもフィールドありますが、関連するところだけ。

 

@AOTSafeClassInitializer
public final class LazyConstantImpl<T> implements LazyConstant<T> {

    @Stable
    private T constant;

    @Stable
    private volatile Supplier<? extends T> computingFunction;

    private LazyConstantImpl(Supplier<? extends T> computingFunction) {
        this.computingFunction = computingFunction;
    }

    public static <T> LazyConstantImpl<T> ofLazy(Supplier<? extends T> computingFunction) {
        return new LazyConstantImpl<>(computingFunction);
    }

 

見慣れないアノテーションが使われていますが、Leyden関連や最適化のヒントになるアノテーションです。

ここで注目しておいていただきたいのが、値を保持するconstantフィールドがvolatileではないということです。そして、ofメソッドの引数のラムダ式はcomputingFunctionフィールドで保持しています。

 

では、保持している値を返すgetメソッドを見ていきましょう。

 

    @ForceInline
    @Override
    public T get() {
        final T t = getAcquire();
        return (t != null) ? t : getSlowPath();
    }

    private T getSlowPath() {
        preventReentry();
        synchronized (this) {
            T t = getAcquire();
            if (t == null) {
                t = computingFunction.get();
                Objects.requireNonNull(t);
                setRelease(t);
                // Allow the underlying supplier to be collected after successful use
                computingFunction = null;
            }
            return t;
        }
    }

 

getメソッドの最初に出てくるgetAcquireメソッドはconstantフィールドを取得するメソッドです。このメソッドについては後でもう一度触れます。

getAcquireメソッドでconstantフィールドをローカル変数のtに代入しています。続いて、tがnullでなければ、tをそのまま返しています。逆に、tがnullならばgetSlowPathメソッドをコールしています。

getSlowPathメソッドの先頭でpreventReentryメソッドをコールしていますが、これはロックを取得している状態で再びロックを取得する(これを再入すると呼びます)ことを防ぐメソッドです。Javaのsynchronizedは再入が可能なロックなのですが、ここではそれを防いでいるということです。

そして、synchronizedでロックを取得し、再びtを取得してnullかどうかをチェックしています。つまりダブルチェックになっているということです。

ダブルチェックをしてtがnullの場合、computingFunctionフィールドに対してgetメソッドをコールしています。これがSupplierのラムダ式の実行を意味しています

つまり、ここで値の初期化を行っています。

初期化した値がnullの場合はrequireNonNullメソッドでチェックしてNullPointerException例外をスローします。これが、前回のエントリーで例外を扱う場合の1の選択肢(ラムダ式でnullを返す)時の挙動になります。

次のsetReleaseメソッドはgetAcquireメソッドの逆です。

そして、computingFunctionにnullを代入しています。つまり、一度Supplierのラムダ式が実行されたら、その後はラムダ式を実行することができないということです。

このようにして、ダブルチェックロックを使って値の初期化を行っています。

しかし、気になるのは、シングルトンでは遅延初期化するフィールドがvolatileだったのにLazyConstantImplクラスではvolatileではないという点です。

この問題はgetAcquireメソッドを見てみれば、理由が分かります。

 

    @SuppressWarnings("unchecked")
    @ForceInline
    private T getAcquire() {
        return (T) UNSAFE.getReferenceAcquire(this, CONSTANT_OFFSET);
    }

 

ここで使われているUNSAFE変数は、一般には使わないようにと言われている危険なjdk.internal.misc.Unsafeクラスです。標準ライブラリだからこそ、使えるということですね。

そして、UnsafeクラスのgetReferenceAcquireメソッドを見てみると...

 

    @IntrinsicCandidate
    public final Object getReferenceAcquire(Object o, long offset) {
        return getReferenceVolatile(o, offset);
    }

 

なんと参照をvolatileで取得するメソッドをコールしていました。

つまり、LazyConstantImplクラスのconstantフィールドはvolatileで定義されてはいないものの、アクセスする時はvolatile相当で行われるということです。

これがconstantフィールドがvolatileで定義されていない理由になります。まぁ、普通にはできない技ですね(そもそもUnsafeクラスは使えないですし)。

 

もう1つ標準ライブラリだからこその技が最適化のヒントとなるアノテーションです。

たとえば、@ForceInlineアノテーションはメソッドのインライン化を行わせるアノテーションです。また、@Stableアノテーションは値が変更されないことを保証して、値を埋め込むなどの最適化を可能にしています。

このような最適化に対するアノテーションを使うことで、実行時最適化をやりやすくしているわけです。

 

まとめ

finalフィールドの遅延初期化を行うLazy Constantの実装を見てきました。

遅延初期化で使われている手法は、シングルトンで使われていたvolatileとダブルチェックロックです。この手法を使う場面というのはなかなかないとは思いますが、知識として知っておくのはよいですね。

そもそも、Lazy Constant自体がそれほど頻繁に使われるAPIではありません。しかし、もしイミュータブルなクラスで遅延初期化をしなければならないような場合はぜひ思い出してやってください。

Lazy Constant

本エントリーはJava Advent Calendar 2025の4日目です。昨日はAsanoさん (@mackey0225) の読書感想文 : 『Javaの10年』でした。

 

11月15日に開催されたJJUG CCC 2025 FallでLazy Constantについてプレゼンしてきました。資料はこちら。

 

Lazy Constantはfinalフィールドを遅延初期化させるためのAPIで、Java 26ではJEP 526で提案されています。

 

JEP 526: Lazy Constants (Second Preview)

https://openjdk.org/jeps/526

 

LazyConstantインタフェース自体は単機能で使い方も簡単なのですが、その導入背景は理解しておいた方がよいと思います。

 

なぜLazy Constant?

Javaでも宣言的なプログラミングスタイルが増えてきたり、並列処理が当たり前に使われるようになってきて、イミュータブル性の重要度が増しています。

また、アーキテクチャー的にもDDDの導入で値クラスを使うことが多くなっています。もちろん、値クラスはイミュータブルです。

 

そこで、イミュータブルなクラスを作ることを考えるわけですが、イミュータブルなクラスの条件の1つにフィールドはすべてfinalにするということがあります。

ここで困るのが、フィールドによっては初期化に時間がかかるものがあることです。たとえば、通信やファイル読み込みなどの外部リソースにアクセスする場合などがこれに相当します。

時間のかかるフィールドの初期化がアプリケーションの起動時にまとまって発生してしまうと、ただでさえいろいろやらなければならない起動時ですが、このようなフィールの初期化のためにさらに起動時間がかかるということになってしまいます。

通常のフィールドであれば、実際にフィールドを使用する時まで初期化を遅らせることができます。しかし、finalフィールドはオブジェクトの生成時にしか初期化することができません。

そこで登場するのがfinalフィールドの遅延初期化をサポートするLazy Constantです。

 

Lazy Constantとは

Lazy Constantは値を1つだけ保持するコンテナのようなものです。

そして、保持する値の初期化は実際に使用する時まで遅延させます。もちろん、スレッドセーフなので並列処理でも使えます。

値の初期化を行うにはSupplierインタフェースを使用します。ようするに、引数なし、戻り値ありのラムダ式ですね。

重要なことが、JVMの最適化を享受しやすい実装になっていることです。LazyConstantオブジェクトから値を取得するときにはgetメソッドを使用する必要があり、しかもgetメソッド内では値が初期化されたかどうかをチェックする必要があります。これらのオーバーヘッドがあるにも関わらず、インライン化などの最適化を行いやすくなっており、最適化後は直接変数にアクセスするのとパフォーマンスが変わらなくなります。

では、このような特徴を持つLazyConstantを使ってみましょう。

 

LazyConstantの使い方

LazyConstantはインタフェースで、パッケージはjava.langです。ですから、import文は必要ありません。

メソッドは4つだけ。しかも、ほぼofメソッドとgetメソッドしか使いません。

• static LazyConstant<T> of(Supplier<T> computingFunction) : LazyConstantオブジェクトのファクトリーメソッド
• T get() : 値を取得するためのメソッド

 

ofメソッドでLazyConstantオブジェクトを生成して、getメソッドで値を取得するというだけです。

たとえば、Consumerクラスで遅延初期化させたいHeavyクラスのオブジェクがあるとしましょう。このオブジェクトをLazyConstantインタフェースを使用して遅延初期化させてみます。

LazyConstantインタフェースのフィールドをheavyConstantとしてfinalで定義します。

そして、実際にheavyConstantフィールドが保持する値を使用するのはconsumeメソッドだとします。

public class Consumer {
    private final LazyConstant<Heavy> heavyConstant
            = LazyConstant.of(() -> new Heavy());

    public void consume() {
        // 初回のgetメソッドコール時に
        // ofメソッドの引数で指定したラムダ式を実行し値を初期化
        // 次からは初期化後の値を取得
        var h = heavy.get();
        IO.println(h);

        // heavyを使用した処理...
    }
}

 

ofメソッドの引数のラムダ式では、Heavyオブジェクトの生成を行っています。オブジェクトの生成だけなのであれば、コンストラクター参照を使用してHeavy::newでも大丈夫です。

そして、heavyフィールドが保持している値を取得するためにgetメソッドを使用します。getメソッドの初回コール時にofメソッドの引数で指定されたラムダ式が実行されます。2回目以降は初期化された値が返ります。

 

では、このConsumerクラスを使ってみましょう。

void main() {
    var consumer = new Consumer();

    consumer.consume();
    consumer.consume();
    consumer.consume();
}

 

Heavyクラスのコンストラクターでは初期化しているというメッセージを標準出力に表示しています。

LazyConstantインタフェースはJava 26ではPreview APIなので、コンパイルや実行には--enable-previewが必要です。

>  java --enable-preview .\Main.java
ノート: C:\test\SomeData.javaはJava SE 26のプレビュー機能を使用します。
ノート: 詳細は、-Xlint:previewオプションを指定して再コンパイルしてください。
Heavy Initializing
Heavy@2002fc1d
Heavy@2002fc1d
Heavy@2002fc1d
> 

 

コンストラクターがコールされているのは1度だけで、それ以降はgetメソッドで返る値は同じオブジェクトになっていることがわかります。

 

初期化にデータが必要な場合

遅延させたい値の初期化に何らかのデータが必要になる場合はどうでしょう。

初期化にSupplierインタフェースを使うので、引数で渡すことはできません。しかし、final変数であればラムダ式の外側の変数も参照できるので次のように書くこともできます。

    public Consumer(final String filename) {
        heavyConstant = LazyConstant.of(() ->  new Heavy(filename));
    }

 

Heavyクラスのコンストラクターでは引数の文字列を表示させるようにしてみました。また、mainメソッドでも文字列を渡しています。

void main() {
    var consumer = new Consumer("Main.java");

    consumer.consume();
    consumer.consume();
    consumer.consume();
}

 

では、実行してみましょう。

>  java --enable-preview .\Main.java
ノート: C:\test\SomeData.javaはJava SE 26のプレビュー機能を使用します。
ノート: 詳細は、-Xlint:previewオプションを指定して再コンパイルしてください。
Heavy Initializing: Main.java
Heavy@2002fc1d
Heavy@2002fc1d
Heavy@2002fc1d
> 

 

このようにラムダ式を書いた時点でのfinal変数であるfilename変数をキャプチャーし、ラムダ式の実行時に使用していることが分かります。

 

初期化時の例外

外部リソースにアクセスするから遅延初期化をしたいということはけっこうあると思います。この時に困るのが例外です。

外部リソースへのアクセスはどうしても例外が発生しがちです。こんな時にどうすればよいのか？

考えられるのは以下の3つの選択肢ではないでしょうか。これについては特にJEPで触れられていないので、さくらばだったらこうするという方法です。

 

• ラムダ式でnullを返す
• 例外をRuntimeException例外にくるんで、スローする
• ラムダ式の返り値をEitherもしくはResultなどにする

 

1つ目の方法は初期化のためのラムダ式で例外が発生した時に、nullを返すというものです。ラムダ式でnullを返すと、getメソッドの内部でNullPointerException例外がスローされます。

このNullPointerException例外をキャッチするという方法です。

この方法は簡単でよいのですが、残念ながら原因となる例外が隠されてしまい、スタックトレースなども引き継ぐことができません。このため、NullPointerException例外が発生したとしても、原因を調べるのが難しくなってしまいます。

 

2つ目のRuntimeException例外を使う方法は、初期化のためのラムダ式のSupplierインタフェースが検査例外をスローできないからです。これはjava.util.functionパッケージの他のインタフェースも同じですね。

そこで、何らかの例外が発生したらRuntimeException例外のcauseにセットして、RuntimeException例外をスローするという方法です。

この方法はスローするRuntimeException例外をドキュメント化しておかないと例外処理を忘れがちという問題があります。

少なくとも、マルチスレッドで使用している場合のUncaughtExceptionにならないようにしなくてはいけません。

この点に注意すれば、まぁ使える方法ではないかなと思います。

 

最後のEitherもしくはResultを使う方法は、例外を値として保存しておいて、ラムダ式の返り値として返すという方法です。

たとえば、Eitherであればleftとrightの2つの値を保持できるようになっており、正常に初期化できた時はleftに保持させ、例外が発生した時にはrightに保持させます。そして、このEitherオブジェクトをラムダ式の返り値として返します。

このため、LazyConstantインタフェースのgetメソッドの戻り値はEitherになり、leftとrightのそれぞれの場合の処理を記述します。

しかし、これだとLazyConstantというコンテナにEitherというコンテナを保持させ、実際に使うにはgetしてgetしなければならないというちょっとめんどくさいことになってしまいます。

こう考えると、finalフィールドのためにEitherを使うのはちょっとやりすぎではないかなと、さくらばは思うわけです。

 

ということで、さくらば的には2つ目のRuntimeException例外を使うかなぁ...

 

コレクションの遅延初期化

LazyConstantインタフェースではコレクションを初期化するのはちょっと難しいのですが、ListインタフェースとMapインタフェースに遅延初期化するためのメソッドが追加されています。

• static List<E> List.ofLazy(int size, IntFunction<? extends E> computingFunction)
• static Map<K, V> Map.ofLazy(Set<? extends K> keys, Function<? super K, ? extends V> computingFunction)

 

たとえば、0から9までを保持するリストを遅延初期化させるのであれば、次のように記述します。

private final List<Integer> nums = List.ofLazy(10, i -> i);

 

ofLazyメソッドを使用して生成したコレクションは、実際にそのコレクションにアクセスした時にofLazyメソッドの引数で指定されたラムダ式を実行して初期化を行います。

 

その他のメソッド

使うことはほぼないとは思いますが、LazyConstantインタフェースの残りの2つのメソッドについても簡単に触れておきましょう。

 

boolean isInitialized()

メソッド名で分かると思いますが、保持している値が初期化が行われたかどうか、つまりgetメソッドが1度でもコールされたかどうかを判定するためのメソッドです。初期化されて入ればtrue、初期化されていなければfalseが返ります。

 

T orElse(T other)

保持している値が初期化されていればその値を返し、初期化されていなければ引数のotherを返します。

注意しなければいけないのは、orElseメソッドの内部ではgetメソッドはコールされません。つまり、値が初期化されていなくても、初期化することはありません。

くり返しますが、初期化されていない場合はotherを返します。

 

まとめ

LazyConstantインタフェースはfinalフィールドを遅延初期化させたい場合に使用するインタフェースです。

それほど使うインタフェースではないとは思いますが、ロガーをfinalフィールドで定義したい場合などに使えます。

遅延初期化の機能だけに注目すれば、finalでないフィールドに対しても使うことが可能です。

とはいうものの、遅延初期化はそれなりにオーバーヘッドがあるので、遅延初期化を必要としないフィールドに対して使うのはやりすぎです。

遅延処理を必要とする場合に使うようにしましょう。

 

使い方だけで、意外に長くなってしまったので、LazyConstantインタフェースでの遅延処理の実装について次回説明することにします。