Сборка мусора: почему объект жив, хотя ссылок на него нет

База: объект умирает, когда пропадает последняя ссылка

У каждого объекта в CPython есть счётчик: сколько ссылок на него сейчас существует. Имя — ссылка. Элемент списка — ссылка. Атрибут другого объекта — ссылка. Когда ссылка появляется, счётчик растёт, когда пропадает — уменьшается. Дошёл до нуля — объект освобождается сразу.

Так устроена обычная сборка CPython — та, что ставится по умолчанию. С 3.13 есть и вторая, без GIL; у правила там есть исключения, они разобраны в конце урока. Ответу уровня Junior они не мешают: для объекта, который создаёт и отпускает один поток, правило верно в обеих сборках.

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

И сразу следствие, на котором спотыкаются: del x не удаляет объект. Он удаляет имя x и уменьшает счётчик на единицу. Если это была последняя ссылка — объект умрёт. Если нет — будет жить дальше.

Проверить «жив ли объект» можно, не удерживая его, — слабой ссылкой из модуля weakref. Она не увеличивает счётчик, а после смерти объекта возвращает None. Этим приёмом сделаны все прогоны урока.

Механизм 1: цикл — единственное, чего счётчик не умеет

Без цикла всё происходит на строке del:

1) без цикла
   до del: жив
   сразу после del: мёртв — освобождён счётчиком ссылок, сборщик не нужен

Теперь две вершины, которые ссылаются друг на друга:

a, b = Node("a"), Node("b")
a.other, b.other = b, a
del a, b

2) цикл из двух вершин
   sys.getrefcount(a) до del: 3
   после del a, b: жив и жив
   gc.collect() вернул 2; теперь: мёртв и мёртв

sys.getrefcount показывает 3: имя a, ссылку из b.other и собственный аргумент функции — третью единицу добавляет сам вызов. После del имён нет, но у каждой вершины осталось по ссылке — от соседа. Счётчик не опустится до нуля никогда: из программы до вершин не добраться, а друг друга они держат.

Такую группу и ищет сборщик циклов. Документация описывает его роль одной фразой:

the collector supplements the reference counting already used in Python (сборщик дополняет подсчёт ссылок, который в Python уже есть).

Он обходит отслеживаемые объекты (контейнеры — списки, словари, экземпляры классов; числа и строки он не отслеживает, у них не бывает ссылок на другие объекты) и находит группы, на которые нет ссылок извне. gc.collect() возвращает число найденных недостижимых объектов — здесь 2. Запускается он и сам, по порогам числа созданных объектов; как устроены эти пороги и поколения, разобрано в статье об управлении памятью.

Механизм 2: объект жив не из-за цикла, а из-за ссылки, которой не видно

На вопрос «почему память не освобождается» первым приходит в голову «где-то цикл». Но объект может держать и обычная ссылка от живого объекта — вполне законно, просто её нет в коде на виду. Ниже три такие ссылки.

Трассировка исключения держит кадр

У исключения есть атрибут __traceback__. Трассировка держит кадр каждой функции, через которую прошло исключение, а кадр — все её локальные переменные. Справочник языка называет это прямо, объясняя, почему имя из except ... as e исчезает после блока:

Прогон проверяет три случая: исключение нигде не сохранено; сохранено в локальную переменную той же функции; сохранено в атрибут живого объекта.

3) исключение и кадр упавшей функции
   исключение нигде не сохранено: payload после выхода из функции — мёртв
   сохранено в локальную err: payload после выхода — жив
     цикл: кадр -> err -> исключение -> __traceback__ -> кадр
     после gc.collect(): мёртв
   сохранено в svc.last_error: payload после выхода — жив
     путь от живого svc: svc -> исключение -> __traceback__ -> кадр -> payload
     gc.collect() при живом svc: жив
     svc.last_error = None: мёртв
   имя e после блока except: NameError — его удалил сам интерпретатор

Второй и третий случаи выглядят одинаково — «payload жив», — а устроены по-разному, и от этого зависит лечение. Локальная err = e возвращает тот самый цикл из справочника: после выхода из функции до него не добраться, и объект ждёт сборщика. С атрибутом svc.last_error всё достижимо от живого сервиса — и сборщик это не тронет: gc.collect() при живом svc объект не освободил. Но и ждать его не нужно: svc.last_error = None, и объект умер на этой же строке. Хранить в атрибуте стоит текст ошибки, а не само исключение.

lru_cache на методе держит self

4) functools.lru_cache на методе
   del rep: жив — self лежит в ключе кеша
   gc.collect(): жив
   Report.total.cache_clear(): мёртв

Кеш живёт на функции, то есть на классе, а self — часть ключа. Документация Python описывает это в FAQ:

The disadvantage is that instances are kept alive until they age out of the cache or until the cache is cleared (Недостаток в том, что экземпляры остаются живыми, пока их не вытеснят из кеша или пока кеш не очистят).

При maxsize=None вытеснения нет вовсе, и каждый экземпляр, у которого хоть раз вызвали метод, живёт до cache_clear() или до конца процесса.

Метод в списке подписчиков держит объект

5) связанный метод в списке подписчиков
   callbacks.append(w.on_event); del w: жив — метод держит __self__
   gc.collect(): жив
   callbacks.clear(): мёртв
   то же через weakref.WeakMethod; del w: мёртв
   weak_callbacks[0]() -> None

w.on_event — связанный метод, объект, у которого в __self__ лежит w. Подписать метод на событие значит держать сильную ссылку на весь объект. weakref.WeakMethod ссылается на него слабо: объект умирает, подписка возвращает None, и её можно выбросить при следующей рассылке.

Механизм 3: __del__ в цикле с 3.4 не мешает сборке

До Python 3.4 цикл, в котором у объекта был __del__, сборщик не трогал: было неясно, в каком порядке вызывать финализаторы, если объекты ссылаются друг на друга. Такие объекты копились в gc.garbage. PEP 442 это снял:

to be able to define and run finalizers for any object, regardless of their position in the object graph (чтобы можно было определять и запускать финализаторы для любого объекта, независимо от его положения в графе объектов).

6) __del__ у обеих вершин цикла
   gc.collect() вернул 2; финализаторы выполнились: ['a', 'b']
   gc.garbage: []

Оба финализатора вызваны, gc.garbage пуст. Но порядок, в котором они вызываются, PEP явно оставляет неопределённым: For CI objects, the order in which finalizers are called (step 2 above) is undefined (Для объектов в циклической изоляции порядок вызова финализаторов (шаг 2 выше) не определён). Здесь вышло a, потом b — полагаться на это нельзя. И в __del__ объекта из цикла сосед может быть уже финализирован.

Глубже: за что платит полная сборка

Полная сборка — gc.collect() без аргументов — обходит все отслеживаемые объекты, в том числе живые: чтобы понять, что группа недостижима, надо знать, на что ссылаются остальные. Поэтому её время растёт с числом живых контейнеров, даже когда мусора нет ни одного:

PY 3.13.7 | лучшее из 7 вызовов gc.collect()

  живых списков   gc.collect()   на объект
         10 000        0.75 мс     45.8 нс
        100 000        3.57 мс     32.8 нс
      1 000 000       39.88 мс     39.6 нс
    пустая куча        0.29 мс

Несколько десятков наносекунд на живой объект — в этой таблице от 32,8 до 45,8 нс: миллион живых списков — почти 40 мс паузы на полную сборку. Сам сборщик запускает полную сборку редко — пороги рассчитаны на то, чтобы большая часть работы шла в младшем поколении, — но процесс с большим долгоживущим кешем в памяти платит за него на каждой такой сборке.

Убрать живое из обхода умеет gc.freeze(), появившийся в 3.7: он переносит всё отслеживаемое в постоянное поколение, и следующие сборки его не обходят. Но придуман он не как общее средство от пауз, а под один случай — о нём ниже.

  тот же миллион живых списков
    до gc.freeze():      38545.7 мкс
    после gc.freeze():       0.3 мкс, в постоянном поколении 1 005 045 объектов

Документация предлагает его для процессов, которые делают fork без exec: сборщик в дочернем процессе не трогает замороженные объекты, и меньше страниц памяти копируется при записи. Как общий приём против пауз он годится с двумя оговорками. Мусорные циклы среди замороженного больше не собираются, пока не вызван gc.unfreeze(), — то есть это память, отданная навсегда. И в сборке без GIL заморозка снимает со сборки не всё; это видно в следующем разделе.

Глубже: сборка без GIL — то же правило, но с исключениями

С 3.13 CPython собирается и без GIL (PEP 703). Счётчик ссылок там устроен иначе: у объекта есть поток-владелец, и операции из этого потока идут по быстрому пути, а из чужого — по общему. Как это сказывается на скорости, разобрано в статье о GIL, как на размере объекта — в статье об управлении памятью. Здесь — что это значит для вопроса «когда объект умрёт».

Главное правило урока держится: экземпляр, созданный и отпущенный одним потоком, умирает на строке del и без GIL. Все шесть опытов bench/gc/alive.py на 3.13t и 3.14t дают тот же ответ «жив или мёртв», что с GIL. Но три вещи расходятся:

2) функция, объявленная на уровне модуля
   сразу после del: жив
   после gc.collect(): мёртв
   для сравнения, вложенная функция сразу после del: мёртв
3) последнюю ссылку удаляет не тот поток, что создал объект
   жив в том потоке сразу после del: 19 из 20
   жив в главном потоке после join(): 0 из 20
4) gc.freeze() и миллион живых списков, лучшее из 7 вызовов gc.collect()
   до gc.freeze():      37272.2 мкс
   после gc.freeze():   23155.0 мкс, в постоянном поколении 1 007 024 объектов

Функция уровня модуля ждёт сборщика. С GIL она умирает на строке del, без GIL — только на gc.collect(); вложенная функция умирает сразу в обеих сборках. Тот же эффект виден и в bench/gc/alive.py: в шестом опыте gc.collect() без GIL вернул 3, а не 2, и третьим оказалась функция тела класса — с GIL её освободил счётчик сразу после создания класса.

Последняя ссылка из чужого потока. Объект создал главный поток, а последнюю ссылку забрал и удалил другой. Сразу после del в том потоке объект был жив в 19 попытках из 20 на 3.14t и в 20 из 20 на 3.13t; в главном после join() — мёртв во всех. С GIL — мёртв сразу, 0 из 20 на всех четырёх версиях. Число попыток напечатано не случайно: результат зависит от расписания потоков.

gc.freeze() снимает не всё. С GIL после заморозки сборка миллиона живых списков занимает доли микросекунды — 0,2–0,3 мкс в этом же прогоне. Без GIL — 23,2 мс из 37,3 на 3.14t и 23,4 из 63,5 на 3.13t: заметная часть работы сборщика остаётся.

Отсюда точная формулировка для собеседования: в обычной сборке CPython объект без цикла умирает сразу, когда счётчик доходит до нуля; в сборке без GIL это верно для объекта одного потока, но не для всех объектов.

Как отвечать на собеседовании

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

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

Если спросят про утечки, хороший ответ начинается не с циклов, а с того, что объект может держать обычная ссылка от живого объекта, которой не видно: исключение в атрибуте держит трассировку, кадр и все его локальные переменные; lru_cache на методе держит self в ключе; метод в списке подписчиков держит объект в __self__. Всё это достижимо, и сборщик такое не тронет. Лечится одной правкой: хранить текст ошибки, чистить кеш, подписываться через weakref.WeakMethod.

Стоит добавить, почему имя из except ... as e исчезает после блока: иначе кадр держал бы исключение, исключение через трассировку держало бы кадр, и получился бы цикл со всеми локальными переменными. Это написано в справочнике языка. И про цену сборки: она растёт с числом живых объектов — миллион живых списков, 39,88 мс на gc.collect() без мусора (3.13.7), — а gc.freeze() убирает их из обхода — в обычной сборке.

Если речь зайдёт о сборке без GIL, стоит сказать, что «умирает на той же строке» там верно не всегда: функция уровня модуля ждёт сборщика, а объект, последнюю ссылку на который отпустил чужой поток, переживает del в этом потоке.

Дальше спросят

Частые заблуждения

История версий

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

class Node:
  pass


gc.disable()
a = Node()
b = Node()
a.other = b
b.other = a
r = weakref.ref(a)
del a, b
print(r() is None)
gc.collect()
print(r() is None)

False
True

True
True

False
False

True
False

Проверьте себя

Чем измерено

Числа этого урока получены этими скриптами. Каждый открывается прямо отсюда — вместе с записью прогона: на чём считали, что получилось и с каким разбросом.

• bench/gc/alive.py
• bench/gc/pause.py
• bench/gc/practice.py
• bench/gc/freethreaded.py