ガベージ・コレクタ(GC)は、アプリケーションの動的メモリー割当てリクエストを自動的に管理します。

ガベージ・コレクションは、次の操作によって自動動的メモリー管理を実行します。

• オペレーティング・システムからメモリーを割り当てたり、メモリーを戻したりします。

• アプリケーションのリクエストに応じて、メモリーをアプリケーションに渡します。

• そのメモリーのどの部分がアプリケーションで使用されているかを判定します。

• 未使用のメモリーをアプリケーションで再使用するために回収します。

Java HotSpotガベージ・コレクションでは、様々な技術を採用して、これらの操作の効率性を改善します。

• 世代別のスカベンジをエージングとともに使用して、再利用可能で大きなメモリー領域が含まれている可能性のあるヒープ内の領域に集中します。

• 複数のスレッドを使用して、並列操作をアグレッシブに実行するか、アプリケーションと同時にバックグラウンドで長時間かかる操作を実行します。

• ライブ・オブジェクトを圧縮することで、連続的な大きな空きメモリーのリカバリを試行します。

ガベージ・コレクタの目的は、手動の動的メモリー管理からアプリケーション開発者を解放することです。開発者は、割当てと割当て解除を照合し、割り当てられた動的メモリーの寿命を注意深く管理する必要性から解放されます。これにより、実行時に追加のオーバーヘッドを費やしていたメモリー管理に関連する、ある種類のエラーが完全になくなります。Java HotSpot VMでは、ガベージ・コレクションのアルゴリズムの選択肢を提供します。

ガベージ・コレクタの選択は、どのような場合に問題になるのでしょうか。アプリケーションによっては、まったく問題になりません。つまり、ガベージ・コレクションによる一時停止が適度な頻度で適度な期間にわたって発生すれば、アプリケーションは問題なく実行できます。ただし、大規模なアプリケーション、特に大量のデータ(複数GB)を保持し、多数のスレッドを使用する、トランザクション率の高いアプリケーションでは、このようにはいきません。

アムダールの法則(特定の問題に対して並列化がもたらす速度の向上は、問題の逐次処理部分によって制限される)は、ワークロードのほとんどは完全には並列化できず、必ず逐次処理される部分があり、その部分は並列処理の恩恵を受けないことを示しています。Javaプラットフォームでは、現在、4つのガベージ・コレクションの代替方法がサポートされていますが、そのうちの1つはシリアルGCで、それ以外のすべては作業を並列化してパフォーマンスを向上させます。ガベージ・コレクションのオーバーヘッドをできるだけ低くすることが重要です。次に例を示します。

図1-1のグラフは、ガベージ・コレクションを除いて、拡張性の高い理想的なシステムをモデルにしています。赤色の線は、単一プロセッサ・システムではガベージ・コレクションにわずか1%の時間しかかからないアプリケーションを示しています。この場合、32個のプロセッサを搭載したシステムでは、スループットは20%を超えて低下します。赤紫色の線はガベージ・コレクションに10%の時間がかかるアプリケーション(単一プロセッサ・アプリケーションでガベージ・コレクションに費やされる時間としてあり得ない値ではありません)を示し、プロセッサを32個に拡張したときのスループットは75%を超えて低下してしまいます。

この図から、小規模なシステムの開発では無視できるスループットの問題が、大規模なシステムへと拡張すると重要なボトルネックになる可能性があることがわかります。ただし、このようなボトルネックを減らすように少し改善するだけで、パフォーマンスが大きく向上する可能性があります。十分に大規模なシステムでは、適切なガベージ・コレクタを選択し、必要に応じてチューニングする価値が大いにあります。

シリアル・コレクタは一般に、特に最新のプロセッサ上で、必要なヒープが最大でも100MB程度の小規模アプリケーションのほとんどに適しています。他のコレクタは、特殊な動作の代償として、オーバーヘッドや複雑さが増加します。他のコレクタが備える特殊な動作をアプリケーションが必要としない場合には、シリアル・コレクタを使用します。シリアル・コレクタが最適な選択肢にならないのは、大容量のメモリーと2個以上のプロセッサを搭載したマシンで動作する、スレッド化の程度が非常に高い大規模なアプリケーションの場合です。アプリケーションがserver-classマシンで実行されている場合、ガベージファースト(G1)・コレクタがデフォルトで選択されます。「エルゴノミクス」を参照してください。