クラス A のオブジェクト a が、クラス B の別のオブジェクト b への参照を保持しているとします。これが b への唯一の参照です。したがって、a へのすべての参照が削除されると、a は GC の準備が整います。これは、b もガベージ コレクションの準備ができているということですか? b には ( a 内に) 参照がありますが、 a に到達できないため、到達できません。
では、このシナリオはどのように機能するのでしょうか。ガベージコレクションの順序を意味します。
クラス A のオブジェクト a が、クラス B の別のオブジェクト b への参照を保持しているとします。これが b への唯一の参照です。したがって、a へのすべての参照が削除されると、a は GC の準備が整います。これは、b もガベージ コレクションの準備ができているということですか? b には ( a 内に) 参照がありますが、 a に到達できないため、到達できません。
では、このシナリオはどのように機能するのでしょうか。ガベージコレクションの順序を意味します。
オブジェクトがルートから到達不能になると、収集されます。GC ルートの説明については、この質問を参照してください。
そのサブグラフ内のノードに到達しないと仮定して、サブグラフ全体が(説明したように)収集されます。
Java (および .NET) は、この種の問題に対処するマーク アンド スイープガベージ コレクションを使用します。
参照カウントベースのシステム (C++ などstd::shared_ptr<T>
) は、到達できない循環依存関係の場合に失敗する可能性があります。これは、Java/.NET GC の問題ではありません。
Java GC は、孤立したオブジェクトのアイランドを収集するのに十分なほどスマートです。したがって、b
ガベージ コレクションの対象にもなります。ここで注意すべき点は、参照はありますが、プログラムのルートから到達できないという意味でライブb
ではないということです。
オブジェクトが相互に内部的に参照していて、プログラムから到達可能な参照がない場合でも、それらは GC の対象になります。ここに図付きの良い説明があります
http://www.thejavageek.com/2013/06/22/how-do-objects-become-eligible-for-garbage-collection/
GCに依存します。JVM は異なる GC を使用するように指示でき、通常は 3 つの GC (eden、copy、markcompact) を 1 つとして使用します。
典型的なGCでは、あなたが説明した状況をrefcountingするときれいに処理され、両方のオブジェクトが収集されます。最初に「a」が注目されて収集され、次に「b」が注目されて収集されます。繰り返しますが、特定の通知方法は GC によって異なります。
それがまさにGCのポイントです。b はメインスレッドから到達できないため、ガベージコレクションされます。重要なのはカウントだけではありません。