歴史：Java 9以前、InflaterやDeflaterのようなクラスにおけるネイティブリソース管理は、Object.finalize()に依存していました。このメカニズムは予測不可能であり、性能オーバーヘッドが大きく、オブジェクトの再生のリスクがあるため、廃止されました。Java 9では、クリーンアップロジックをオブジェクトのライフサイクルから切り離し、オブジェクトがクリーンアップ中に到達不可能であることを保証するために、PhantomReferenceとReferenceQueueを利用したCleaner APIが導入されました。
問題：Inflaterの実装では、基盤となるネイティブのz_stream構造体を明示的にend()メソッドを介して解放しなければ、ネイティブメモリリークを防ぐことができません。アプリケーションスレッドが明示的にend()を呼び出す一方で、Cleanerスレッドが登録されたクリーンアップアクションを実行しようとすると、競合状態が発生します。適切な同期がない場合、両方のスレッドが同じネイティブポインタを解放しようとし、ダブルフリーエラーが発生するか、一方のスレッドが他方が解放した後にリソースにアクセスする（解放後の使用）が発生し、JVMがクラッシュする（SIGSEGV）可能性があります。
解決策：解決策は、ネイティブクリーンアップがどのスレッドによって開始されても正確に1回だけ実行されることを保証するために、AtomicBoolean状態フラグを利用します。明示的なend()メソッドとCleanerのクリーンアップアクションはこのフラグに対して比較および設定（CAS）操作を行います。フラグをfalseからtrueに正常に遷移させたスレッドだけが、ネイティブ解放ルーチンを呼び出すことができます。このロックフリーアプローチは、圧縮操作に必要な高性能を維持しつつ、スレッドセーフを保証します。
高スループットのログ圧縮サービスが、ログエントリを数百万件毎日処理し、プールされたDeflaterインスタンスを使用して割り当てオーバーヘッドを最小限に抑えています。リソース使用を最適化するために、開発者はDeflaterインスタンスの使用をプールに戻す前に明示的にend()を呼び出すパターンを実装し、同時に処理パイプラインにおける未処理の例外によってリークしたインスタンスをガーベジコレクションで回収するようにしました。
システムはピーク負荷時にまばらですが重大なJVMクラッシュ（SIGSEGV）を経験し、コアダンプはネイティブzlibライブラリ内のメモリ破損を示しました。調査の結果、Deflaterインスタンスがプールに戻されると、アプリケーションスレッドがend()を呼び出しましたが、インスタンスが同時にガーベジコレクションの対象になった場合、Cleanerスレッドも同じネイティブz_streamハンドルをクリーンアップしようとしました。このネイティブリソースへの非同期アクセスが、プロセスを予測不可能にクラッシュさせました。
考慮された最初の解決策は、Deflaterインスタンスへのすべてのアクセスをsynchronizedブロックまたはメソッドを使用して同期することでした。このアプローチは相互排除を保証し、競合状態を効果的に防ぎます。しかし、これは高頻度の圧縮パイプラインで重大な競合オーバーヘッドを引き起こし、複数のスレッドから同時に不正にアクセスされた場合、デッドロックのリスクがありました。
2番目のアプローチは、クリーンアップ状態を追跡するためにAtomicBooleanを使うことでした。明示的なend()メソッドとCleanerアクションは、ネイティブリソースに触れる前にこのフラグを原子操作で確認および設定するべきでした。これによって、ロックフリーの安全性が提供され、パフォーマンスペナルティが最小化されましたが、原子的な確認の後に拘束されることなくネイティブハンドルにアクセスされないように細心の実装が要求されました。
3番目の選択肢は、明示的なend()呼び出しを完全に削除し、リソース管理のためにCleanerのみに依存することでした。これによって競合状態は完全に排除されましたが、ネイティブメモリ解放のタイミングに予測不可能さが導入され、GCサイクルがネイティブ構造体の割り当て率に遅れてしまった場合、ガーベジコレクションの中で重大なメモリ圧迫を引き起こす可能性がありました。
チームはAtomicBooleanアプローチ（解決策2）を選択しました。なぜなら、それは可能な場合（明示的呼び出し）に決定論的即時クリーンアップを提供し、クリーンアップが後で実行された場合でも安全性を確保したからです。彼らはラッパークラスを修正してAutoCloseableを実装し、原子状態チェックがネイティブ解放を保護することを保証しました。これにより、クラッシュは完全に解決され、必要なスループットが維持され、プロダクションでのネイティブメモリ関連のクラッシュが排除されました。
どうやってCleaner** APIは**Object.finalize()に内在するオブジェクトの再生問題を防ぐのか？
Object.finalize()では、finalize()メソッドが実行されるときオブジェクトは依然として到達可能であり、this参照が有効であるため、オブジェクトが自分自身を静的フィールドに保存して再生することができます。この再生は、オブジェクトが繰り返し再生され続ける限り、ガーベジコレクションを無期限に遅延させます。Cleaner APIは、PhantomReferenceを使用することでこれを防ぎます。Cleanerのクリーンアップアクションが実行されると、対象（クリーンアップされるオブジェクト）はすでにファントム到達可能状態にあり、強い、柔らかい、または弱い参照がないため再生することはできません。クリーンアップアクションはオブジェクト自体のメソッドではなく、別のRunnableであり、クリーンアッププロセス全体を通じてオブジェクトが到達不可能であることを保証します。
JVMシャットダウン中にThread.interrupt()がCleanerスレッドを停止するのに無効な理由は何か、そしてその意味は？
Cleanerスレッドはデーモンスレッドであり、**ReferenceQueue.remove()**で継続的にブロックし、ファントム参照が利用可能になるのを待っています。ReferenceQueue.remove()は割り込みによってInterruptedExceptionをスローしますが、Cleanerの実装はこの例外をキャッチし、無限循環を続けるため、実際に割り込みを無視します。この設計は、シャットダウンシーケンス中であっても重要なリソースクリーンアップが完了することを保証します。しかし、登録されたクリーンアップアクションが無限にハング（例：ネットワークタイムアウトを待っている、または無限ループに詰まっている場合）した場合、Cleanerスレッドは決して終了しません。これは、クリーンアップが解放すべきリソースを待っている他の非デーモンスレッドがある場合、JVMの優雅なシャットダウンを妨げる可能性があります。
もしCleanerのクリーンアップアクションが、クリーンアップされるオブジェクトに対して強い参照を保持している場合、どのような壊滅的なメモリリークが発生するか？
もしCleaner.register()に渡されるRunnableがオブジェクトに強い参照を保持する（例：this::cleanupMethodやthisを参照するラムダを介して）と、致命的な参照循環を作成します。Cleanerは、各クリーンアップRunnableへの参照を保持するCleanableオブジェクトの内部セットを維持します。そのRunnableが元のオブジェクトを参照している場合、オブジェクトはCleanerスレッド自体から強く到達可能になります。結果として、オブジェクトはファントム到達可能にならず、PhantomReferenceはキューに入らず、クリーンアップアクションは実行されません。その一方で、オブジェクトはガーベジコレクションされることができず、深刻なメモリリークが発生し、クリーンアップするごとに登録されるオブジェクトによって無限に成長していき、最終的にOutOfMemoryErrorを引き起こします。