「循環構造を見つけられない」
オブジェクトを持っているとしましょうA
。その作業を行うためにA
呼び出される別のオブジェクトが必要です。B
ただし、その作業を行うためにB
呼び出される別のオブジェクトが必要です。C
しかし、何らかの理由C
でポインタが必要です。A
したがって、依存関係グラフは次のようになります。
A -> B -> C -> A
オブジェクトの参照カウントは、それを指している矢印の数でなければなりません。この例では、すべてのオブジェクトの参照カウントは 1 です。
メイン プログラムが実行中にこのような構造を作成し、メイン プログラムに へのポインタがA
あり、A
のカウントが 2 になったとします。この構造が範囲外になるとどうなりますか? A
の参照カウントが 1 に減らされます。
しかし、注意してください!現在、、、A
およびB
すべてC
の参照カウントは 1ですが、メイン プログラムからはアクセスできません。したがって、これはメモリ リークです。ウィキペディアには、この問題を解決する方法の詳細があります。
「スペースを段階的に再利用できます」
ほとんどのガベージ コレクターには、実行を一時停止し、使用されなくなったオブジェクトを解放する収集期間があります。マーク アンド スイープ システムでは、これがスイープ ステップです。欠点は、スイープの間の期間中、メモリが増え続けていることです。オブジェクトは作成直後に使用されなくなることがありますが、次のスイープまで再利用されることはありません。
参照カウント システムでは、参照カウントがゼロになるとすぐにオブジェクトが解放されます。大きな一時停止や大きなスイープ ステップはありません。使用されなくなったオブジェクトは、コレクションを待つだけでなく、すぐに解放されます。したがって、コレクションは、最後のコレクション以降に使用されなくなったすべてのオブジェクトを一括収集するのではなく、使用されなくなったオブジェクトを増分的に収集するという点で増分的です。
もちろん、この漸進主義には落とし穴があります。つまり、大量の小さな GC よりも大量の GC を実行する方がコストがかからない可能性がありますが、それは正確な実装によって決まります。