歴史はJava 9のjava.lang.ref.Cleanerの導入にさかのぼります。これは、予測不可能な実行タイミング、パフォーマンスペナルティ、および再生攻撃を含むセキュリティ脆弱性に悩まされた非推奨の**Object.finalize()**メソッドの代替として登場しました。根本的な問題は、**finalize()**がオーバーライドされたメソッドがthisの参照を生きたオブジェクトグラフに戻すことを許可していたために発生します。これにより、ガベージコレクターによって到達不可能と見なされたオブジェクトが「再生」され、単一構築単一破壊の不変条件に違反し、ネイティブリソースが一貫性のない状態に残される可能性があります。
解決策は、Cleaner実装内のPhantomReferenceのセマンティクスを利用します：清掃アクションは、参照そのものではなく、Runnableまたは清掃アクションオブジェクトのみを受け取ります。そして、参照はファントム到達可能状態であることが保証されます。つまり、すでにファイナライズされており、再生できない状態であり、清掃ロジックが不可逆的に到達不可能なオブジェクトで動作することを確保します。
public class NativeResource { private static final Cleaner cleaner = Cleaner.create(); private final long nativeHandle; public NativeResource() { nativeHandle = allocateNative(); cleaner.register(this, new CleanupAction(nativeHandle)); Reference.reachabilityFence(this); } private static class CleanupAction implements Runnable { private final long handle; CleanupAction(long handle) { this.handle = handle; } @Override public void run() { releaseNative(handle); } } private native long allocateNative(); private static native void releaseNative(long handle); }
私たちのチームは、ImageProcessorオブジェクトがJNIを介して割り当てられたネイティブOpenCVバッファをラップする高スループットの画像処理パイプラインを管理していました。最初は、cvReleaseImage()を呼び出すために**finalize()**に依存していましたが、Javaヒープの安定性にもかかわらず、ネイティブメモリ枯渇に時折遭遇しました。それは、ネイティブメモリでの使用後解放エラーを示唆する断続的なセグメンテーションフォルトを伴っていました。
考慮した最初のアプローチは、**finalize()**を保持しながら、「死んだ」オブジェクトを追跡するために静的マップで同期を取る復活ガードを追加することでした。これは予測不可能なレイテンシに苦しみました - ファイナライズがヒープ圧力が始まった後に数分遅れて発生する可能性があり、ガードロジック自体が追跡マップ内の「死んだ」オブジェクトに対して強い参照を維持することによりメモリリークを引き起こしました。皮肉にも、それらの収集を完全に防ぎつつ、再生レース条件を許しました。
2番目のアプローチは、インスタンスコンストラクタ内でネイティブポインタをラムダにキャプチャしてjava.lang.ref.Cleanerを素朴に使用することでした：cleaner.register(this, () -> free(pointer))。これによりファイナライズの遅延は避けられましたが、もしthisが構築中に脱出した場合、早期収集のリスクがありました。そして、もしラムダがImageProcessorインスタンスであってポインタ値だけでなく、強い参照サイクルを作成した場合、ガベージコレクションが参照を防ぐことになりましたが、実際に再生を防ぐこともありました。
私たちは3番目のアプローチを選択しました：ネイティブポインタのみ（longとして）を保持し、Runnableを実装する静的ネストされたCleaningActionクラスを実装しました。私たちは成功したネイティブ割り当ての直後に清掃アクションを登録し、登録が完了するまでオブジェクトが到達可能であり続けることを保証するためにコンストラクタの最後で明示的に**Reference.reachabilityFence(this)**を呼び出しました。これにより、再生リスクとネイティブリークが排除され、メモリ圧力のインシデントは毎日の発生から六ヶ月間ゼロに減少しました。
なぜCleanerはWeakReferenceやSoftReferenceではなくPhantomReferenceを使用し、このことがどのようにして清掃アクションが参照の状態にアクセスできないことを防止するのか？
PhantomReferenceは、ガベージコレクターが回収可能なオブジェクトを特定することを可能にしますが、オブジェクトがファントム到達可能状態に入った後、プログラムコードが参照のフィールドやメソッドにアクセスできないようにします。WeakReferenceとは異なり、get()を介して参照の取得を許可するWeakReferenceは、PhantomReferenceは常にget()からnullを返すため、清掃アクションはオブジェクトが論理的に破壊されているという仮定のもとで操作され、再生試行や事後不変条件を侵害する可能性のある状態の検査を防止します。
Object.finalize()の文脈における「再生」攻撃とは何であり、なぜそれが型システムの安全保証に違反するのか？
再生は、**finalize()**メソッドがthis参照を静的フィールドまたは生きたオブジェクトグラフに保存することで発生します。これにより、ガベージコレクターが再生可能とマークした後にオブジェクトが再び到達可能になります。これは、オブジェクトのコンストラクタが正確に1回実行され、そのファイナライザが多くても1回実行されるという不変条件に違反し、悪意のあるまたはバグのあるコードが、ネイティブリソースが解放され、Javaフィールドがまだアクセス可能な部分的に破壊された状態のオブジェクトを観察できることを許可し、使用後解放の脆弱性や不整合なオブジェクト動作を引き起こします。
Reference.reachabilityFenceは、JVMの最適化の再配置やオブジェクト参照の排除を防ぐコンパイラバリアとして機能し、特にクリティカルセクションが完了するまでオブジェクトが早期に公開されるのを防ぎます。これは、ネイティブリソースの割り当ての後、Cleanerにオブジェクトを登録する際には厳密に必要です。これがないと、JVMは、登録呼び出しの前に、登録が必要なくなったと判断する可能性があり、清掃が実行され、コンストラクタがオブジェクトの初期化を続けている間にリソースを解放し、リソースの破損を引き起こす可能性があります。