GarbageCollection

以前の職場にいた同僚(Postdoc・外国人)が言っていた言葉を思い出しました。
「DoctorはGarbageCollection(GC)されるんだよ。Doctorオブジェクトは生まれて、Tenureになったものは生き残るけど、そうでないものはGCされてJunkになる。」

ここでいうDoctorといのはお医者さんではなく我々のような博士なのですが、特に印象に残っているのは「Junkになる」の部分です・・・

これの元ネタはJavaVM1.3以降に搭載されている世代別GC(Generational Garbage Collection）という、ガベージコレクションの一手法です。ガベージコレクションは、もう使われていない（参照のリンクが切れた）オブジェクトのメモリ領域を解放する処理ですが、処理中はStopTheWorldといって基本的にはプログラムの動作の一切を止める必要があります。
で、GCにかかる時間を少なくするために、オブジェクト置場のメモリ領域を2つに分けて、すぐ使われなくなる短命なオブジェクトの領域と、ずっと存在し続けるオブジェクトの領域を作ります。前者をYoungGeneration、後者をOldGenerationといいます。YoungGenerationは積極的に回収を行い、OldGenerationはメモリ領域が不足するようだったら回収する、というのが基本方針です。また、YoungGenerationでの回収を一定回数生き延びたオブジェクトは、OldGenerationに移されます(Tenured領域といいます)。

なんか、Doctorと一緒ですよね。

GCによる回収を逃れる方法というのがあるのですが、それはObjectPoolというやつです。参照のリンクが切れないように、親玉のObjectに常に参照していてもらうようにする、という方法ですね。（本来は、オブジェクト生成のコストを削減する目的で使う。）
若い世代だけで参照し合っていてもバッサリ切られてしまう可能性は消えないので、やはり親玉が必要なのです。もちろん、OldGenerationの親玉もGCされてしまう可能性がないわけではないのですが。

参考：
ITPro　Java技術最前線「メモリーを意識してみよう」　第2回　GCの仕組みを理解する
http://itpro.nikkeibp.co.jp/article/COLUMN/20060612/240657/

ThinkIT 連載：GoF以外のデザインパターン 第2回 Object Poolパターン
http://thinkit.co.jp/article/934/1