Javaでは、オブジェクトへの参照がなくなった場合、ガベージコレクターがしばらくしてからオブジェクトを再利用することを理解しています。
しかし、ガベージコレクターは、オブジェクトに参照が関連付けられているかどうかをどのようにして知るのでしょうか。
ガベージコレクターはある種のハッシュマップまたはテーブルを使用していますか？
編集：
私はgcがどのように一般的に機能するかを尋ねていないことに注意してください。本当に、私はそれを求めていません。
具体的には、gcがどのオブジェクトが生きているのか、どれが死んでいるのかを効率的に知る方法を求めています。
そのため、gcはある種のハッシュマップまたはセットを維持し、オブジェクトが持つ参照の数を一貫して更新するという質問で言いますか？
典型的な最新の JVM は、いくつかの異なるタイプのガベージ コレクターを使用します。
しばらく存在していたオブジェクトによく使用されるタイプの 1 つは、Mark-and-Sweep と呼ばれます。基本的には、既知の「ライブ」オブジェクト (いわゆるガベージ コレクション ルート) から開始し、オブジェクト参照のすべてのチェーンをたどり、到達可能なすべてのオブジェクトを「ライブ」としてマークします。
これが完了すると、スイープステージは、「ライブ」としてマークされていないオブジェクトを再利用できます。
このプロセスが機能するには、JVM がすべてのオブジェクト参照のメモリ内の場所を認識している必要があります。これは、ガベージ コレクターが正確であるために必要な条件です(これは Java のものです)。
Java にはさまざまなガベージ コレクション戦略がありますが、それらは基本的に、既知のアクティブなオブジェクトから到達可能なオブジェクトを追跡することによって機能します。
How Garbage Collection works in Javaという記事にすばらしい要約がありますが、実際の詳細については、5.0 Java[tm] 仮想マシンを使用した Garbage Collection のチューニングを参照してください。
実行中のプログラムのどのポインタからもアクセスできなくなったオブジェクトは、ガベージと見なされます。最も単純なガベージ コレクション アルゴリズムは、到達可能なすべてのオブジェクトを反復するだけです。残ったオブジェクトはガベージと見なされます。このアプローチにかかる時間は、ライブ オブジェクトの数に比例します。これは、大量のライブ データを維持する大規模なアプリケーションには適していません。
J2SE Platform バージョン 1.2 以降、仮想マシンには、世代別コレクションを使用して組み合わされた多数の異なるガベージ コレクション アルゴリズムが組み込まれました。単純なガベージ コレクションはヒープ内のすべてのライブ オブジェクトを調べますが、世代別コレクションはほとんどのアプリケーションで経験的に観察されたいくつかのプロパティを利用して余分な作業を回避します。
これらの観察された特性の中で最も重要なのは乳児死亡率です。...
つまり、イテレータのような多くのオブジェクトは非常に短い時間しか存続しないため、古いオブジェクトよりも新しいオブジェクトの方がガベージ コレクションの対象となる可能性が高くなります。
最新のチューニング ガイドについては、以下をご覧ください。
ちなみに、ガベージ コレクション戦略を推測しないように気をつけてください。過度に熱心に使用しSystem.gc()たり不適切な-XXオプションを使用したりすると、多くのプログラムのパフォーマンスが台無しになることがわかっています。
GC は、オブジェクトを可能な限り迅速に削除できることを認識します。このプロセスを管理することは期待されていません。
しかし、 を使用して非常に丁寧に実行するように GC に依頼することができますSystem.gc()。システムへのヒントにすぎません。GC はその時点で実行する必要はなく、特定のオブジェクトなどを削除する必要もありません。なぜなら、GC は大きなボスであり、私たち (Java プログラマー) はその奴隷に過ぎないからです... :(