レコードクラスは、コンポーネントフィールドをfinalとして暗黙的に宣言し、構築後の変更を禁止します。コンパクトコンストラクタを使用する場合（形式的なパラメータリストを省略する）、Javaコンパイラはthis.component = ...による明示的なフィールド割り当てを禁止します。これは、コンストラクタ本体の実行後すぐに割り当てバイトコードを自動的に注入するためです。この設計により、開発者はフィールドを直接割り当てるのではなく、パラメータ変数を自分で再割り当てする必要があります（例：component = Objects.requireNonNull(component)）。このため、レコードは参照を格納するため、ミュータブル引数をコンパクトコンストラクタ内でクローンすることに失敗すると、外部での変更がレコードの不変性の保証を侵害するため、ミュータブルコンポーネントに対する防御的コピーが不可欠になります。
高頻度取引プラットフォームの開発中、アーキテクチャチームは、BigDecimal価格とjava.util.Dateタイムスタンプを含む不変のマーケットデータティックを表現するためにレコードクラスを採用しました。Dateの可変性は、レコードのインスタンス化後にプロデューサースレッドがタイムスタンプオブジェクトを変更できるレースコンディションを許すため、重大な脆弱性を呈しました。これにより、監査証跡が破損する可能性があります。
この脆弱性を軽減するために三つのアプローチが考慮されました。最初の戦略は、java.time.Instant、不変の時間型に移行することでした。これにより防御的コピーのオーバーヘッドが排除され、現代のJava時間APIと一致しましたが、Dateオブジェクトをシリアライズするレガシーミドルウェアコンポーネントの大規模なリファクタリングが必要になり、受け入れられない配達リスクが内在しました。
第二のオプションでは、静的ファクトリメソッドを使用して防御的コピーを行い、その後標準コンストラクタに委譲しました。このアプローチはカプセル化を維持しましたが、レコード固有の簡潔な構文と自動的な構造的平等の利点を放棄し、標準コンストラクタパターンを期待するデシリアライズフレームワークを複雑化させました。
最終的な解決策は、入力を検証し防御的なクローンを作成するためにコンパクトコンストラクタを使用しました：timestamp = (Date) timestamp.clone();。これにより、コンパイラの暗黙的なフィールド割り当てを利用してコピーを格納し、元の参照を保持しなくて済むため、スレッドセーフが確保され、レコードのセマンティクスを損なうことがありませんでした。
実装は、時系列操作攻撃を効果的に防ぎ、数百万の同時トランザクションを含むその後のストレステスト中にデータ腐敗のインシデントをゼロにしました。
通常のコンストラクタで許可されるにもかかわらず、なぜコンパクトコンストラクタ内でthis.fieldの明示的な割り当てがコンパイラによって拒否されるのか？
Java言語仕様では、コンパクトコンストラクタは標準コンストラクタに展開され、コンパイラがパラメータリストを合成し、フィールド割り当てを追加します。レコードコンポーネントは暗黙的にfinalであるため、コンパクトコンストラクタの本体はフィールドが「確実に未割り当て」と見なされる事前割り当て状態で実行されます。明示的なthis.fieldの割り当てはfinal変数への第二の割り当てとなり、確実な割り当てルールに違反しますが、パラメータ変数の再割り当ては行われる割り当てを隠すだけで許可されます。
コンパクトコンストラクタ内での防御的コピーは、ObjectInputStreamを使用する際にデシリアライズ攻撃からどのように保護しますか？
従来のSerializableクラスとは異なり、JVMはUnsafe割り当てによってインスタンス化し、リフレクションまたはreadObjectメソッドでポピュレートしますが、デシリアライズされたレコードは常にストリーム提供の引数を使って標準コンストラクタを呼び出して再構築されます。したがって、コンパクトコンストラクタ内で実行される防御的コピーのロジックは、後で変更のためにミュータブルオブジェクトを注入しようとする悪意あるまたは破損した入力ストリームを自動的にサニタイズします。開発者はこのメカニズムを見落としがちで、標準デシリアライズ中に必要でも呼び出されることもないreadObjectやreadResolveメソッドをレコードに誤って実装します。
コンパクトコンストラクタとレコードの明示的に宣言された標準コンストラクタとの間にバイトコードの違いは何ですか？
コンパクトコンストラクタは、invokespecial（Objectのコンストラクタを呼び出す）に続いてコンストラクタのロジックが続き、各コンポーネントに対するコンパイラ生成のputfield命令が続くバイトコードにコンパイルされます。一方、明示的な標準コンストラクタは開発者によって書かれたputfield操作を埋め込んでいます。この違いにより、コンパクトコンストラクタはフィールド初期化後に同じメソッド内で検証やロジックを実行できず、初期化シーケンスが根本的に制約され、暗黙の割り当てが実行される前にパラメータ変数でのすべての防御的変換を行う必要があります。