GC の動作は単純明快。「ルート（オブジェクトを参照している変数）の存在しないオブジェクトを回収し、メモリを解放する」ただそれだけである。殆どにおいて、プログラム、或いはプログラマからは GC は全く透過的だ。GC の動作の詳細を気にする必要はない。だが、GC について知識を持っていると役に立つ事がある。パフォーマンス、アンマネージリソースの確実な解放、アンマネージコードとの連携、ルートがないように見えるオブジェクトの維持、ルートがあるように見えるオブジェクトの GC 回収、etc。知識は無用なトラブルを回避してくれる。
Finalize を実装するかしないかでは、そのクラスのオブジェクトの GC パフォーマンスは変わる。Finalize を実装しているクラスのオブジェクトは一度の GC では決して回収されないからだ。
ある時点で、オブジェクトA、B にはルートが存在し、オブジェクトC、D にはルートが存在しない。オブジェクトB、C には Finalize が実装されていたとする。図にするとこのようになる。
オブジェクトが Finalize を実装している場合は、Manage heap にオブジェクトが確保されると同時に、Finalization list にも登録される。これでオブジェクトが Finalize 呼び出しを必要としている事がマークされるわけだ。登録されるのはオブジェクトへのポインタだ。ここで GC が実行されたとしよう。
オブジェクトA、B にはルートが存在するので当然 GC の対象とならない。オブジェクトC、Dにはルートが存在しないので GC の対象となる。しかし、オブジェクト C は回収されずに生き残る。ガベージコレクタはオブジェクト C を回収しようとする際に、Finalization list にオブジェクト C のリストが存在する事を検出し、回収しないでオブジェクト C を F-reachable queue に登録する。ここでも登録するのはオブジェクトへのポインタだ。F-reachable queue に登録されいてるオブジェクトは言わば「Finazlize 実行待ち」という事である。
F-reachable queue にエントリが登録されると、あるスレッドが活性化される。Finazlize 呼び出し専用スレッドだ。これは通常のアプリケーションを実行しているスレッドよりも優先度が高く、対象のオブジェクトの Finalize を呼び出していく。この際、Finalize の呼び出し順には何のルールもない事を覚えておいて損はないだろう。F-reachable queue にはどのような順で参照が登録されるかは全く不明だ。クラス設計の際に Finalize の呼び出し順序に前提を設けて設計してはならない。
Finzalize 呼び出し専用スレッドの仕事が終わったときの図はこのようになる。
さあ、いよいよ 2 回目の GC である。オブジェクト C にはもう何もルートがないのできれいに回収される。
…はずだが、実はまだまだ回収されない。.NET Framework の GC は、アルゴリズムに「ジェネレーション」という概念を設けている。先程までの説明にはジェネレーションの概念が入っていないため、Finalize 実装オブジェクトは 2 回の GC で回収されるように思えるが、実際には最低でも 3 回以上の GC 実行が必要となる。というように、Finalize 実装オブジェクトは想像以上に回収されにくい。本当に Finalize を実装すべきかどうかをよく検討する必要があるだろう。
勉強会では「Dispose を必ず呼ぶ事をルールで強制し、Finalize は実装しない」という選択も場合によっては有効だろう、という意見も出た。更に、検証に役立つツールとして CLR プロファイラ も紹介された。脳みそに叩き込んでおいて欲しい。
この辺りの知識は プログラミングMicrosoft .NET Framework 第2版
に詳しい。未読ならば一読を。
つづく。
This is CLR - GC (Section 2)