この保証は、クラス初期化に関連するJavaメモリモデル（JMM）のハプンズ-前ルールから導き出されます。JVMがクラスのstaticフィールドまたはメソッドに初めてアクセスする際、クラスの初期化フェーズをまず完了しなければなりません。このフェーズでは、クラスオブジェクトに特有の内部ロックの下で、staticイニシャライザブロックやフィールドの代入が実行されます。その結果、静的イニシャライザ内で行われる書き込み（シングルトンインスタンスの構築など）は、クラスにアクセスするスレッドによるそのフィールドの後続の読み取りとの間にハプンズ-前エッジを形成し、synchronizedキーワードやvolatile宣言を必要とせずに構築された状態の完全な可視性を保証します。
public class ConnectionPool { private ConnectionPool() { // 費用のかかるTCPハンドシェイクとスレッド生成 } private static class Holder { static final ConnectionPool INSTANCE = new ConnectionPool(); } public static ConnectionPool getInstance() { return Holder.INSTANCE; // Holderクラスの初期化をトリガー } }
問題: 財務取引アプリケーションは初期のTCPハンドシェイクとスレッド生成のために構築コストが高いConnectionPoolシングルトンを必要としましたが、軽量な診断モードでは不要である可能性もありました。イager初期化は、プールが未使用のままでも起動時に数百ミリ秒を無駄にすることになり、ダブルチェックロッキングは、命令再配置を防ぐためにvolatileセマンティクスと順序バリアの慎重な取り扱いを必要としました。
ソリューション1: イager初期化: このアプローチでは、クラスがロードされるときに静的フィールドが初期化されます。これは実装が簡単で、JVMによってスレッドセーフが保証されます。ただし、プールが決してアクセスされない場合の構築コストを回避するという要件には失敗し、診断モードでのリソースを大幅に無駄にし、展開の起動時間を不必要に増加させます。
ソリューション2: 同期アクセサ: getterをsynchronizedでラップすることで、すべてのスレッド間の安全性が確保され、コードもシンプルですが、インスタンスが存在した場合でもすべての呼び出し元がモニターを取得する必要があるため、高頻度の取引負荷下で深刻なボトルネックを生じます。
ソリューション3: イニシャライゼーションオンデマンドホルダー: これはstatic final ConnectionPoolインスタンスを持つプライベート静的クラスConnectionPoolHolderを定義し、getInstanceが単にConnectionPoolHolder.INSTANCEを返します。これは、JVMの遅延クラスロードを活用します：ホルダークラスはgetInstanceが呼び出されたときにのみ初期化され、クラス初期化ロックは明示的な同期やvolatileのオーバーヘッドなしで安全な公開を保証します。
選ばれたソリューション: チームは、起動後のパフォーマンスにオーバーヘッドがゼロで、Javaメモリモデルの下での安全性が保証されるため、ホルダーイディオムを選択しました。これはレイジー初期化とランタイムの効率性の完璧なバランスを実現しました。
結果: アプリケーションは、競合する負荷下でプール参照のサブマイクロ秒アクセスレイテンシを達成し、重い初期化を初使用まで遅延させ、診断モードでの起動オーバーヘッドを排除し、高ボリュームの取引セッション中の競争状態から解放されました。
ホルダークラスの初期化中にシングルトンコンストラクタが例外をスローした場合、後続のスレッドに何が起こりますか？
staticイニシャライザが例外をスローすると、JVMはクラスを初期化失敗としてマークし、（原因をラッピングして）ExceptionInInitializerErrorをスローします。重要なことに、ConnectionPoolHolderにアクセスしようとする後続のスレッドは、ルート原因が一時的であった場合（例えば、ネットワークの一時的な利用不可など）でも、NoClassDefFoundErrorを受け取ります。ダブルチェックロッキングとは異なり、例外ブロック内での再構築を試みる可能性があるに対し、ホルダーイディオムは外部回復ロジックを必要とします。これは、クラスが定義されたClassLoaderのライフタイムの間、初期化失敗状態のままだからです。
イニシャライゼーションオンデマンドホルダーパターンは、マルチテナントコンテナ内のインスタンススコープシングルトンに適応できますか？
いいえ。このパターンは、staticフィールドとクラスレベルの初期化ロックに厳密に依存しています。インスタンススコープやテナントごとのシングルトンの場合、ホルダーはテナントコンテキストの内部クラスである必要がありますが、クラス初期化ロックはClassLoaderごとであり、コンテナインスタンスごとではありません。これにより、テナント間でインスタンスが共有される（セキュリティと分離のリスク）か、テナントインスタンス内で明示的な同期が必要になることになり、パターンの目的であるロックフリーアクセスを無効にします。候補者はしばしば、クラスレベルのレイジーローディングとオブジェクトレベルのレイジーローディングを混同します。
複数のClassLoader階層がアプリケーションサーバー環境に関与する場合、このイディオムはどのように振る舞いますか？
各ClassLoaderはホルダークラスの独自のコピーを独立して初期化します。TomcatやWildFlyでは、シングルトンクラスがウェブアプリケーションと共有親ローダーの両方に存在する場合、またはウェブアプリが再デプロイされ（新しいClassLoaderを作成）、異なるインスタンスが存在します。これにより、JVMプロセス全体でのシングルトン契約が破られます。このパターンは、単一のクラスローディングネームスペース内でのスレッド安全性を保証しますが、クラスローダーの隔離が強制されるモジュラー環境において、グローバルJVMシングルトンセマンティクスを提供しません。これが重要な違いです。