Краткий ответ

Метод __del__ может воскресить объект: во время финализации он сохраняет ссылку на self в глобальной переменной или другом живом объекте. Поэтому объект, который считался недостижимым, снова становится достижимым и продолжает занимать память.

В современных версиях CPython наличие __del__ само по себе не делает цикл ссылок навсегда неубираемым, но воскрешение, побочные эффекты и неопределённый порядок финализации делают такой механизм опасным для управления ресурсами.

Исторический контекст

В CPython освобождение объектов долгое время в основном связывалось с подсчётом ссылок: когда число ссылок становится нулевым, объект обычно уничтожается немедленно. Метод __del__ был предусмотрен как пользовательский финализатор, чтобы выполнить действия перед уничтожением объекта.

Однако подсчёт ссылок не обнаруживает циклы. Для них нужен сборщик циклического мусора, а финализаторы усложняют этот процесс: выполнение пользовательского кода может изменить граф ссылок прямо во время сборки. Современный Python умеет безопаснее обрабатывать многие циклы с финализаторами, но не устраняет риск воскрешения объекта.

Постановка проблемы

Представьте объект, содержащий ссылку на самого себя. После удаления внешней ссылки он недостижим, но его внутренний цикл сохраняется. Сборщик мусора может обнаружить такой цикл и подготовить объекты к уничтожению.

Если __del__ в этот момент поместит объект в глобальный список, кеш или другой доступный контейнер, объект снова станет достижимым. Память и связанные с объектом ресурсы не будут освобождены, хотя исходный код уже удалил последнюю внешнюю ссылку.

Это может привести к росту памяти, неожиданному продлению жизни файловых дескрипторов, сокетов или блокировок. Дополнительная проблема состоит в том, что порядок вызова финализаторов и состояние связанных объектов не должны использоваться как надёжный протокол освобождения ресурсов.

Подробное решение

Ключевой механизм называется воскрешением объекта. Во время выполнения __del__ объект ещё существует, поэтому сохранение self в живом контейнере создаёт новую сильную ссылку:

import gc

survivors = []

class Node:
    def __init__(self):
        self.link = self

    def __del__(self):
        survivors.append(self)

node = Node()
del node
gc.collect()
print(len(survivors))  # 1: объект воскрес

survivors.clear()
gc.collect()           # теперь объект может быть освобождён

Сначала объект образует цикл через link. После удаления переменной node он недостижим, но __del__ сохраняет его в survivors. Цикл уже не является недостижимым, поэтому память освобождается только после удаления ссылки из survivors и последующей обработки сборщиком.

В Python финализатор обычно не следует рассматривать как аналог надёжного конструктора контекста. В частности, нельзя полагаться на точный момент вызова __del__, порядок финализации нескольких объектов, доступность глобальных переменных при завершении интерпретатора или успешное освобождение внешних ресурсов.

Для файлов, соединений, блокировок и транзакций предпочтительнее явное закрытие либо протокол контекстного менеджера через with. Если нужен callback при уничтожении объекта без продления его жизни, обычно уместнее слабая ссылка или weakref.finalize, но и финализатор не заменяет явное управление критическими ресурсами.

Ситуация из практики

В сервисе объект соединения содержит ссылку на объект журнала, а журнал косвенно ссылается обратно на соединение. После обработки запроса соединение удаляется, но его __del__ добавляет диагностическую запись в глобальный список. Память растёт при каждом запросе, потому что сборка цикла воскрешает соединение.

Рассматривались три варианта. Оставить __del__ было просто, но это сохраняло скрытое владение объектами и делало поведение зависимым от сборщика. Заменить его на вызов close() требовало дисциплины со стороны вызывающего кода. Использовать контекстный менеджер требовало небольшого изменения интерфейса, зато фиксировало границу владения ресурсом и гарантировало закрытие при выходе из блока.

Был выбран контекстный менеджер с явным close(), а диагностические данные стали храниться отдельно от соединения. Это устранило цикл владения и сделало освобождение соединения предсказуемым; __del__ оставили только как необязательный защитный сигнал о некорректном использовании, без сохранения self и без основной логики очистки.

Что кандидаты часто упускают

Всегда ли объект с __del__ остаётся в gc.garbage?

Нет. В современных версиях CPython циклы с финализаторами во многих случаях могут быть корректно финализированы и собраны. Попадание в gc.garbage зависит от конкретной ситуации, настроек отладки сборщика и наличия действительно неубираемых объектов, например объектов расширений с проблемной финализацией. Поэтому утверждение «любой цикл с __del__ неизбежно течёт» устарело.
Что произойдёт, если __del__ воскресит объект?

Объект снова станет достижимым и не будет освобождён в текущем цикле сборки. Обычно финализатор объекта не следует рассчитывать на повторный вызов после последующего исчезновения воскрешённой ссылки, поэтому такой объект может остаться без повторной очистки. Это ещё одна причина не использовать воскрешение как часть штатной логики приложения.
Почему __del__ нельзя считать надёжным способом закрыть файл?

Момент вызова зависит от реализации Python и достижимости объекта. В CPython подсчёт ссылок часто даёт быстрое освобождение, но циклы, альтернативные реализации Python и завершение интерпретатора нарушают такую гарантию. Явный close() или контекстный менеджер лучше выражает владение ресурсом и позволяет корректно обработать исключения.