または、新しいGCで質問するかもしれませんが、それは重要ですか？
その場合、ルックアップテーブルを介して、または弱参照（さらに多くのメモリ）を使用してノード間のリンクを管理することが望ましいか、すべてのノードが相互にポイントするだけで問題ありません。これは、ノードまたはリンクの削除によってそれへのすべての参照がnullに設定される「dispose」メソッドがあることを前提としています。
問題は、RAMに大規模なデータベースがある場合、グラフで多くの長いランダムサイクルを評価する必要がある場合、GCのパフォーマンスに大きな打撃を与えるでしょうか？か否か？
ガベージコレクションへのマークアンドスイープアプローチは、オブジェクトグラフのトポロジにまったく影響されません。すでにマークされているオブジェクトに到達するとすぐに、そのすべての指示対象もマークされていると見なされるため、構造をどのように設計しても、それほど害を及ぼすことはありません。
私のアドバイスは、コードを可能な限り自然に問題に適合させることに執着し、他の懸念についてはかなり緩慢にすることです。実際のパフォーマンス/メモリの問題が発生した場合にのみ、停止して最適化について考えるときが来ます。
HotSpotVMのガベージコレクターは参照カウントを使用しません。マーク/スイープ/コンパクトコレクターまたはコピーコレクターのいずれかがあり、どちらもそのルート（すべてのアクティブなスレッドの呼び出しスタック上のローカル変数、静的フィールドなど）。
基本的に、オブジェクトがどのルートからも到達できない場合は、他のデッドオブジェクトがいくつ参照していても、オブジェクトは単にデッドになります。このコンテキストでのデッドは、実際にはオブジェクトのメモリがすでに解放されていることを意味するのではなく、オブジェクトが次の実行中にGCによって再利用（削除）されることを示しているだけです。
簡単に言うと、グラフトラバーサル中にGCがアクセスするすべてのオブジェクトは生きており、他のすべてのオブジェクトは死んでいます。
したがって、グラフ構造へのすべての外部参照をnullにすると、保持している内部参照の数に関係なく、グラフ構造全体がガベージコレクションされます。
これは、Bob Leeによるマーク＆スイープアルゴリズムの優れた説明です。
http://www.youtube.com/watch?v=KTC0g14ImPc#t=177s 以降の同じ動画： http ：//www.youtube.com/watch？v = KTC0g14ImPc＃t = 2917s
JavaのGCが循環参照によって壊れていたとしたら、かなりがっかりするでしょう。幸い、そうではありません。しかし、私はあなたの質問のデータベース部分を理解していませんでした。あなたが実際にやろうとしていることについてもう少し具体的になれば、それは大いに役立つと思います。