☕Javaプログラミング言語 第4版-16：メモリの自動管理：ガベージコレクションと参照の強さ

✅この記事の要約：Java仮想マシンがオブジェクトのメモリを自動的に回収するガベージコレクション（GC）の基本と、オブジェクトの到達可能性（Reachability）のモデルを解説します。また、System.gc()によるGCへの干渉方法、リソース解放のためのファイナライゼーション（Finalization）の制限、そしてオブジェクトの回収を制御するための参照オブジェクト（Reference Objects）の概念（SoftReference、WeakReferenceなど）を探ります。到達可能性が実行時の仮想マシンの状態によって決定される仕組みに焦点を当てます。
Abstract : 
This chapter explains the basics of Java's Garbage Collection (GC) and the model of object Reachability. It covers how to interact with GC using System.gc(), the limitations of Finalization for resource release, and the concept of Reference Objects (SoftReference, WeakReference, etc.) to control object reclamation. We highlight how reachability is determined by the actual state of the Virtual Machine at runtime.

俳句風 :  参照断ち メモリの海に ゴミは消える

はじめに：プログラマの責務を超えたメモリ管理

この記事では、『THE Java™ Programming Language, Fourth Edition』の第17章「Garbage Collection and Memory（ガベージコレクションとメモリ）」の解説をします。

Java仮想マシン（JVM）では、オブジェクトはnewを使用して作成されますが、そのメモリをプログラマが明示的に解放するための対応するdelete操作はありません。
オブジェクトがプログラム内で参照されなくなったとき、そのオブジェクトはガーベージ（ごみ）と見なされ、ガベージコレクション（GC）と呼ばれるプロセスによって検出および回収され、メモリスペースが解放されます。

17.1. 単純なモデルと到達可能性（Reachability）

ガベージコレクションは論理的に2つのフェーズに分けられます。
1つはライブオブジェクト（生きたオブジェクト）をデッドオブジェクト（回収されるオブジェクト）から分離すること、もう1つはデッドオブジェクトのストレージを回収することです。

ライブオブジェクトとは、実行中のコードから到達可能（reachable）なオブジェクト、つまりコードの何らかのアクションによって依然として使用される可能性があるオブジェクトを指します。
ガベージコレクタは、到達不可能なオブジェクトのみを回収できます。

17.2. ガベージコレクタとの連携

プログラマが不要になったオブジェクトを明示的に破棄する方法はありませんが、RuntimeクラスとSystemクラスの便利なメソッドを通じて、ガベージコレクタに介入するよう要求できます。

public void gc()メソッドは、仮想マシンに未使用オブジェクトのリサイクルに努力を払うように要求します。
ただし、この要求によってGCが実行されることが保証されるわけではありません。

17.3. Finalization（ファイナライゼーション）の制限

クラスは、オブジェクトが回収される前に実行される特別なクリーンアップメソッドとしてfinalizeメソッドを定義できます。
これは、開いているファイルなどの非オブジェクトリソースの解放に使用される可能性があります。
しかし、オブジェクトがfinalizeメソッドを通じてリソースを解放する場合、GC中にのみリソースが解放されるため、リソースのクリーンアップには遅すぎる可能性があることに注意が必要です。

17.4. 到達可能性の状態と参照オブジェクト

オブジェクトは、強い参照（通常の参照）がなくなって初めてガベージコレクションの対象となります。
しかし、ウェブブラウザのキャッシュされた画像のように、特定の参照があるにもかかわらず、メモリが逼迫した場合にはオブジェクトを回収してほしい状況が存在します。

このような場合のために、参照オブジェクト（Reference Objects）が用意されています。
これらは、オブジェクトへの参照を保持しながらも、それがオブジェクトを到達可能に保つ唯一の参照である場合に、GCによる回収を強制しないようにするための特別な参照を提供します。

17.5.1. Referenceクラス

参照オブジェクト型はjava.lang.refパッケージに格納されており、その基本となるのがジェネリックな抽象クラスReference<T>です。

Referenceクラスは以下のメソッドを提供します。

• public T get(): この参照オブジェクトの参照先オブジェクトを返します。

• public void clear(): この参照オブジェクトをクリアし、参照先オブジェクトがない状態にします。

• public boolean enqueue(): この参照オブジェクトを登録されている参照キュー（もしあれば）に追加します。

参照オブジェクトによって参照されるオブジェクトは、コンストラクタ引数を通じてバインドされます。
Referenceを直接サブクラス化することはできず、また、参照オブジェクトが参照するオブジェクトを変更する手段もありません。

17.5.2. 参照の強さ（Strengths of Reference）

参照オブジェクトには、強度の弱い順にSoftReference<T>、WeakReference<T>、PhantomReference<T>の3種類があります。これらは、オブジェクトが通過しうる到達可能性の段階に対応しています。

1. 強到達可能 (Strongly reachable): 少なくとも1つの強い参照（通常の参照）の連鎖を通じて到達できるオブジェクト。

2. ソフト到達可能 (Softly reachable): 強く到達可能ではないが、ソフト参照を含む少なくとも1つの連鎖を通じて到達可能なオブジェクト。

17.5.3. 参照キュー（Reference Queues）

オブジェクトが到達可能性の状態を変化させたとき、そのオブジェクトへの参照が参照キューに配置されることがあります。
GCはこれらのキューを使用して、到達可能性の変化についてコードと通信します。
このキューは、到達可能性の変化を検出するための最良の方法であり、参照オブジェクトのコンストラクタで特定のキューを関連付けることができます。

17.5.4. Finalizationと到達可能性の真実

オブジェクトは、弱到達可能（またはそれ以下）になったときにファイナライズ可能になります。
到達可能性は、ソースコードの文脈によって決定されるのではなく、実行時の仮想マシンの実際の状態によって決定されます。
仮想マシンは、ソースコードの単純な検査が示すよりもずっと早くオブジェクトを到達不可能にするような、特定の最適化を実行する可能性があるためです。

気づきとポスト構造主義的な問い

気づき

Javaのメモリ管理システムは、プログラマからメモリ解放の責任を取り上げることで生産性を高めていますが、その核心である到達可能性の判断は、ソースコードという「書かれた契約」ではなく、実行時環境（VM）の動的かつ不透明な最適化に委ねられています。
これは、プログラマが信じているはずのオブジェクトの「ライフタイムの保証」が、実はVMの内部的な判断という「見えない権威」によって覆されうることを示唆しています。
特に参照オブジェクトの仕組みは、プログラマがメモリ回収の決定権の一部をVMに「委譲」しつつも、弱い参照を通じてその裏で「監視」を続けているという、人間と機械間の複雑な権力関係を反映しているようです。

ポスト構造主義的な問い

ガベージコレクションは、オブジェクトが「意味を失った」（到達不能になった）瞬間にその「存在」（メモリ）を抹消するプロセスです。
もし到達可能性がVMの最適化によって早まる可能性があるならば、ソースコードの論理的な参照がまだ存在しているにもかかわらず、オブジェクトが「実質的に存在しない」と宣言される瞬間が生じます。このとき、オブジェクトの存在とは、物理的なメモリ上の領域に依存するのではなく、実行時のVM内部で維持される「参照の言説」にのみ依存していると言えるでしょうか。
オブジェクトの死（回収）は、プログラマの意図（コード）とは切り離された、システム自身の「自己言及的な終了宣言」にすぎないのでしょうか。

励ましのメッセージ

ガベージコレクションとメモリモデルは、Javaの「舞台裏」を理解する上で非常に重要です。
特に、参照オブジェクト（WeakReferenceなど）を使いこなすことは、キャッシュやリソースマネージャのような複雑なコンポーネントを設計する上で、メモリ効率と堅牢性を両立させる鍵となります。オブジェクトの到達可能性が、ソースコードの見た目以上に流動的であるという事実を認識し、その上で安全なコードを書くことが、真のJavaエキスパートへの道です。
gc()を呼び出すことでGCに介入できることは知っておきつつ、通常はGCのタイミングに頼らないリソース管理（例えば、try-finallyによるストリームの確実なクローズ）を優先しましょう。
引き続き学習を深めていきましょう！

関連記事とマガジン

執筆者：東北イタコ（Tohoku I-ST）

以上です。