Niepowodzenie w abstrakcji w rzeczywistości nie polega na tym, że zbieranie śmieci jest niedeterministyczne, ale raczej na tym, że obiekty są „zainteresowane” rzeczami, do których się odwołują, i nie są zainteresowane rzeczami, których nie posiadają Bibliografia. Aby zobaczyć, dlaczego, rozważ scenariusz obiektu, który utrzymuje licznik częstotliwości malowania określonej kontrolki. Podczas tworzenia subskrybuje zdarzenie „malowania” formantu, a po usunięciu rezygnuje z subskrypcji. Zdarzenie click po prostu zwiększa pole, a metoda getTotalClicks()zwraca wartość tego pola.
Kiedy obiekt licznika jest tworzony, musi powodować zapisanie odwołania do siebie w kontrolowanym przez niego kontrolce. Formant naprawdę nie dba o obiekt licznika i byłby równie szczęśliwy, gdyby obiekt licznika i odwołanie do niego przestały istnieć, ale tak długo, jak istnieje odwołanie, będzie wywoływał procedurę obsługi tego obiektu za każdym razem maluje się. Ta akcja jest całkowicie bezużyteczna dla kontroli, ale byłaby przydatna dla każdego, kto kiedykolwiek wezwałby getTotalClicks()obiekt.
Gdyby np. Metoda utworzyła nowy obiekt „licznika farb”, wykonała jakąś akcję na kontrolerze, zaobserwowała, ile razy odmalowano kontrolkę, a następnie porzuciła obiekt licznika farb, obiekt pozostałby objęty zdarzeniem nawet choć nikomu nie zależy, czy przedmiot i wszystkie odniesienia do niego po prostu znikną. Jednak obiekty nie kwalifikują się do kolekcji, dopóki sama kontrola nie będzie. Gdyby metoda ta była wywoływana wiele tysięcy razy w ciągu życia kontrolki [prawdopodobny scenariusz], mogłaby spowodować przepełnienie pamięci, ale z uwagi na fakt, że koszt N wywołań prawdopodobnie wynosiłby O (N ^ 2) lub O (N ^ 3), chyba że przetwarzanie subskrypcji było bardzo wydajne, a większość operacji nie wymagała żadnego malowania.
Ten konkretny scenariusz można rozwiązać, utrzymując słabe odniesienie do obiektu kontrolnego zamiast obiektu silnego. Model słabej subskrypcji jest pomocny, ale nie działa w ogólnym przypadku. Załóżmy, że zamiast chcieć mieć obiekt, który monitoruje jeden rodzaj zdarzenia z jednego elementu sterującego, chcieliśmy mieć obiekt rejestrujący zdarzenia, który monitoruje kilka elementów sterujących, a mechanizm obsługi zdarzeń w systemie był taki, że każdy element sterujący potrzebował odwołania do innego obiektu rejestrującego zdarzenia. W takim przypadku obiekt łączący kontrolkę z rejestratorem zdarzeń powinien pozostać przy życiu tylko tak długo, jak długo obakontrola jest monitorowana, a rejestrator zdarzeń pozostaje użyteczny. Jeśli ani kontrolka, ani rejestrator zdarzeń nie zawierają silnego odniesienia do zdarzenia łączącego, przestanie istnieć, mimo że nadal jest „przydatne”. Jeśli jedno z nich zawiera silne zdarzenie, żywotność łączącego obiektu może zostać bezużytecznie przedłużona, nawet jeśli drugi umrze.
Jeśli w kosmosie nie ma żadnego odniesienia do obiektu, można go bezpiecznie uznać za bezużyteczny i wyeliminować z istnienia. Fakt, że istnieje odwołanie do obiektu, nie oznacza jednak, że obiekt jest „użyteczny”. W wielu przypadkach faktyczna użyteczność obiektów będzie zależeć od istnienia odniesień do innych obiektów, które - z perspektywy GC - są z nimi całkowicie niezwiązane.
Jeśli obiekty zostaną powiadomione deterministycznie, gdy nikt nie będzie nimi zainteresowany, będą mogli wykorzystać te informacje, aby upewnić się, że każdy, kto skorzysta z tej wiedzy, zostanie o tym poinformowany. W przypadku braku takiego powiadomienia nie ma jednak ogólnego sposobu ustalenia, które obiekty są uważane za „przydatne”, jeśli znany jest tylko zbiór istniejących odniesień, a nie znaczenie semantyczne przypisywane tym odniesieniom. Zatem każdy model, który zakłada, że istnienie lub nieistnienie referencji jest wystarczające do zautomatyzowanego zarządzania zasobami, byłoby skazane na zagładę, nawet gdyby GC mógł natychmiast wykryć porzucenie obiektu.