Невдача в абстракції насправді полягає не в тому, що збирання сміття не є детермінованим, а скоріше в ідеї, що об’єкти "зацікавлені" у речах, на які вони посилаються, і не цікавляться речами, до яких вони не затримуються. посилання. Щоб зрозуміти чому, розглянемо сценарій об’єкта, який підтримує лічильник того, як часто малюється певний елемент управління. Під час створення він передплачує подію "фарби" управління, а при видаленні відміняє підписку. Подія клацання просто збільшує поле, і метод getTotalClicks()повертає значення цього поля.
Коли створений лічильник об'єкта, він повинен викликати збереження посилання на себе в контролі, який він контролює. Контроль насправді не переймається лічильником об'єкта, і він би був такий же щасливий, якщо лічильний об'єкт та посилання на нього припиняють своє існування, але поки існує посилання, він буде викликати обробник подій цього об'єкта щоразу вона малює себе. Ця дія є абсолютно марною для контролю, але була б корисна всім, хто коли-небудь зазиватиме getTotalClicks()об’єкт.
Якщо, наприклад, методом було створити новий об'єкт "лічильник фарби", виконати якусь дію над елементом управління, спостерігати, скільки разів керування перефарбовували, а потім відмовлятися від об'єкта лічильника фарб, об'єкт залишатиметься підписаним на подію навіть хоча ніхто ніколи не піклується про те, щоб об’єкт та всі посилання на нього просто зникли. Об'єкти, однак, не отримали право на збір, доки сам контроль не відбудеться. Якби метод був таким, до якого протягом життя елемента керували б багато тисяч разів [правдоподібний сценарій], це може спричинити переповнення пам’яті, але для того, що вартість N викликів, ймовірно, буде O (N ^ 2) або O (N ^ 3), якщо обробка підписки не була дуже ефективною і більшість операцій насправді не передбачала жодного фарбування.
Цей конкретний сценарій можна вирішити, надавши керуванню зберігати слабке посилання на зустрічний об'єкт, а не на сильний. Модель із слабкою підпискою є корисною, але не працює в загальному випадку. Припустимо, що замість того, щоб мати об'єкт, який відстежує один вид події з одного керування, потрібно було мати об'єкт реєстратора подій, який здійснював моніторинг декількох елементів керування, а механізм обробки подій системи був таким, що кожному елементу управління потрібна довідка до іншого об’єкта реєстратора подій. У цьому випадку об'єкт, що пов'язує елемент керування з реєстратором подій, повинен залишатися живим лише до тих пір, поки вони обидвакерований контроль і реєстратор подій залишаються корисними. Якщо ні контроль, ні реєстратор подій не мають чіткого посилання на посилання, що пов'язує, воно перестане існувати, хоча воно все ще є "корисним". Якщо будь-який має сильну подію, термін служби об'єкта, що зв'язується, може бути марно продовжений, навіть якщо інший помирає.
Якщо жодної посилання на об'єкт не існує ніде у Всесвіті, об'єкт може бути безпечно вважатися марним та усунутий від існування. Факт існування посилання на об’єкт, однак, не означає, що об’єкт є "корисним". У багатьох випадках фактична корисність об'єктів буде залежати від наявності посилань на інші об'єкти, які - з точки зору GC - абсолютно не пов'язані з ними.
Якщо об'єкти детерміновано повідомляються, коли ніхто їх не цікавить, вони зможуть використовувати цю інформацію, щоб переконатися, що хтось, хто отримав би користь від цих знань, буде проінформований. Однак за відсутності такого повідомлення немає загального способу визначити, які об’єкти вважаються "корисними", якщо відомий лише той набір посилань, який існує, а не семантичне значення, яке додається до цих посилань. Таким чином, будь-яка модель, яка передбачає, що існування або відсутність посилань є достатньою для автоматизованого управління ресурсами, була б приречена, навіть якщо GC могла миттєво виявити залишення об'єкта.