На senior интервью по Python почти никогда не хватает ответа уровня «в Python есть reference counting и иногда запускается GC». Обычно хотят понять, знаешь ли ты механизм времени жизни объекта в CPython, понимаешь ли разницу между reference counting и cyclic GC, умеешь ли объяснить, почему Python процесс может расти по RSS даже без «классической утечки», можешь ли диагностировать это в production. В актуальном CPython важно еще что модель GC изменилась: начиная с Python 3.14, generation 1 удалено, threshold2 игнорируется, а сборщик циклов стал incremental с моделью young/old, хотя на интервью до сих пор часто спрашивают старую схему 0/1/2.

Эта статья – не обзор, а именно «подноготная реализации» в терминах CPython: структуры PyObject, поле ob_refcnt, роль ob_type, контракт tp_traverse, служебные GC-заголовки, алгоритм вычитания внутренних ссылок и практические production-выводы. Все примеры и формулировки ниже ориентированы на то, чтобы по ним можно было готовиться именно к senior-level ответам.

Зачем вообще разбираться в GC так глубоко

Наверное каждый, кто готовится к экзаменам, задается вопросом: зачем мне вообще это знать? как оно пригодится?
Это нужно, чтобы код в проде не был для тебя чёрным ящиком. Глубокое понимание GC и памяти помогает не просто писать фичи, а понимать, как сервис реально живёт под нагрузкой: почему растёт память, откуда берутся latency spikes, г��е мы удерживаем лишние ссылки, почему деградируют long-running workers. То есть это даёт тебе не академические знания, а более точную инженерную модель рантайма – за счёт этого ты можешь дебажить проблемы, лучше проектировать код и реже создавать такие проблемы сам.
Для backend-разработчика на Python управление памятью – не академическая тема, а часть инженерной практики. В long-running сервисах, воркерах, Celery-процессах и API-инстансах проблемы обычно проявляются не как «упал malloc», а как рост RSS, хвостовая латентность, редкие паузы, накопление object graphs, циклические ссылки через ORM/контексты/кэши и сложная диагностика «почему память не возвращается». При этом сам CPython устроен иначе, чем JVM: его основной механизм lifetime management – reference counting, а cycle GC – только надстройка, которая собирает то, что не может добрать refcount.

Архитектура управления памятью в CPython

PyObject: с чего начинается почти любой объект

Если заглянуть внутрь CPython, почти любой объект в системе начинается с заголовка PyObject.

В Python/C API он выступает как общий базовый префикс для всех объектов. В этом заголовке хранится две критически важные вещи: счётчик ссылок и указатель на тип объекта.
По сути, объект в CPython – это не какая-то «магическая сущность», а довольно простая конструкция: небольшой служебный заголовок плюс данные конкретного типа (payload).

В упрощённом виде это выглядит примерно так:

typedef struct _object {
  Py_ssize_t ob_refcnt;
  PyTypeObject *ob_type;
} PyObject;

Реальная реализация в CPython немного сложнее – используются дополнительные макросы и обёртки. Но для понимания работы памяти и для технических интервью важно именно это: у каждого объекта есть ob_refcnt (счётчик ссылок) и ob_type (указатель на структуру типа).

Для объектов переменной длины используется структура PyVarObject, где к этому заголовку добавляется ещё одно поле – ob_size.

ob_refcnt: счетчик сильных ссылок

ob_refcnt – это reference count объекта. Каждый раз, когда у объекта появляется новый владелец ссылки, счётчик увеличивается. Когда владелец исчезает – счётчик уменьшается.

На уровне C API этим управляют специальные макросы и функции: Py_INCREF, Py_DECREF, Py_REFCNT.

Важно понимать один нюанс. В документации Python отдельно отмечается, что в современных версиях CPython значение refcount не всегда стоит трактовать как абсолютно точное количество логических ссылок. Некоторые оптимизации (например, механизм immortal objects) могут нарушать эту интуитивную модель. Тем не менее для понимания жизненного цикла объектов reference counting по-прежнему остаётся ключевым механизмом управления памятью.

На практике это означает следующее:

  • присвоение объекта переменной увеличивает refcount;

  • помещение объекта в контейнер (например, в list или dict) обычно также увеличивает refcount;

  • удаление из контейнера или потеря владельца ссылки уменьшает refcount;

  • возврат и передача объектов через C API зависят от протокола владения ссылками: borrowed reference или new reference.

Именно различие между borrowed reference и new reference является одним из самых частых источников ошибок при ра��работке C-расширений: утечек памяти и double free. Поэтому эту тему очень любят проверять на технических интервью.

ob_type: как объект знает, что он умеет

Поле ob_type указывает на структуру PyTypeObject – описание типа объекта.

Через эту структуру интерпретатор понимает, как именно должен вести себя объект. Например:

  • как объекты сравниваются друг с другом;

  • как они освобождаются из памяти;

  • участвует ли объект в cyclic GC;

  • умеет ли он обходить свои внутренние ссылки через tp_traverse;

  • умеет ли очищать их через tp_clear;

  • как именно выполняется деаллокация через tp_dealloc.

Другими словами, ob_type – это своего рода переход от сырых данных в памяти к поведению объекта.

Как работает reference counting

Базовая mental model очень простая:

создали объект -> refcount = 1
появился новый владелец -> INCREF
владелец исчез -> DECREF
если refcount стал 0 -> объект можно уничтожать

Но важно понимать, что refcount меняется не только при a = obj и del a. Он меняется при операциях контейнеров, хранении в frame, замыканиях, globals, локалах интерпретатора, аргументах функций, возвращаемых значениях и любых C API взаимодействиях. Поэтому в production коде объект может жить значительно дольше, чем кажется, если смотреть только на одно место его использования.

Что происходит, когда refcount == 0

Когда Py_DECREF() уменьшает счётчик ссылок до нуля, CPython обычно уничтожает объект сразу, вызывая деаллокатор типа.

В документации по type objects говорится, что текущая реализация CPython делает immediate destruction, когда refcount становится равен нулю. При этом важно помнить: это деталь реализации CPython, а не гарантированное свойство языка Python в целом.

Упрощенно цепочка выглядит так:

Py_DECREF(obj)

if (--ob_refcnt == 0) {
    tp_dealloc(obj)
        release referenced fields
        possibly finalize
        free memory
}

Если объект участвует в cyclic GC, перед освобождением его обычно нужно сначала удалить из структур сборщика мусора (UnTrack), и только после этого очищать поля и освобождать память. Это отдельно оговаривается в документации C API для объектов, поддерживающих cyclic garbage collection.

На уровне Python это часто выглядит так, будто объект «умирает сразу» после выхода из функции:

class A:
  def __del__(self):
    print("finalized")
    
def f():
  x = A()
  
  f()

В CPython __del__ обычно выполнится сраз�� после выхода из f(): локальная ссылка исчезает, refcount падает до нуля, и объект немедленно деаллоцируется.

Но корректнее формулировать это так: «в CPython это обычно происходит сразу», а не «Python гарантирует немедленный вызов», поскольку другие реализации Python могут вести себя иначе.

Почему одного reference counting недостаточно

Главная проблема – циклические ссылки

Reference counting отлично работает, пока у объекта либо есть внешний владелец, либо его нет совсем, но у этого подхода есть проблема: циклические ссылки.

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

Именно поэтому в CPython существует дополнительный механизм – cycle GC.

Классический пример:

a = []
b = []

a.append(b)
b.append(a)

del a
del b

После del a и del b обе переменные ушли, но два списка все еще ссылаются друг на друга. Reference counting не видит, что этот маленький подграф уже недостижим извне. Он видит только, что у обоих объектов refcount не нулевой. Поэтому без дополнительного алгоритма такие циклы оставались бы в памяти навсегда.

Более реалистичный пример

В реальном сервисе циклы обычно выглядят не как два списка, а как связанный object graph:

class RequestContext:
  def __init__(self):
    self.user = None
    
class User:
  def __init__(self):
    self.ctx = None
    
ctx = RequestContext()
user = User()

ctx.user = user
user.ctx = ctx

del ctx
del user

Такой цикл легко возникает через ORM-модели, request context, backrefs, callback chains, closures и event-loop state. Пока объектный граф сам себя держит, pure refcount его не освободит.

Как устроен cyclic garbage collector

Сначала важная историческая оговорка

На интервью часто до сих пор спрашивают: «Расскажи про поколения 0, 1 и 2». Это был правильный ответ для классического CPython до Python 3.14. Но в текущем gc модуле ситуация изменилась: начиная с Python 3.14, generation 1 removed, gc.collect(1) означает уже не «собрать второе поколение старой схемы», а increment of collection, gc.get_objects(generation=1) возвращает пустой набор, а threshold2 игнорируется. Документация модуля gc описывает текущую модель как young и old generations, а в What's New in Python 3.14 отдельно зафиксировано, что collector стал incremental и это снижает worst-case pause times на больших heap'ах.

То есть ответ сегодня должен звучать так:

Исторически в CPython был трехпоколенческий cycle GC: generation 0 / 1 / 2. В актуальном CPython 3.14+ collector incremental и внешне фактически работает с young и old

Но старую терминологию на интервью все еще нужно знать.

Когда запускается GC

Модуль gc отслеживает разницу между количеством allocations и deallocations. Когда число net allocations превышает значение threshold0, запускается сборка мусора.

В актуальной схеме при запуске GC просматриваются объекты young generation и часть объектов old generation. Параметр threshold1 определяет, какую долю старшего поколения нужно просканировать за один запуск.

Согласно документации, при значении по умолчанию (threshold1 = 10) за одну коллекцию проверяется примерно 1% объектов old generation.

Параметр threshold2 в Python 3.14 больше не используется и фактически игнорируется.

Из этого следует важный вывод: GC в CPython – это не полный проход по всей памяти при каждой сборке. Вместо этого используется механизм, который запускается по триггерам и обходит только tracked container objects. Причём в современных версиях CPython этот обход выполняется ещё и порционно, чтобы не создавать длинных пауз в работе интерпретатора.

Promotion объектов

В старой трёхпоколенческой mental model новый объект сначала попадал в generation 0. Если он переживал сборку мусора, то продвигался дальше – в generation 1, а затем в generation 2.

В актуальной модели (Python 3.14+) схема упростилась. Новые tracked объекты сначала находятся в young generation, а объекты, пережившие сборку, перемещаются в old generation.

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

Именно эта идея остаётся неизменной, даже несмотря на изменения во внутренней реализации алгоритма.

Внутренности GC: что реально лежит под капотом

gc_head: дополнительный заголовок перед объектом

Не каждый объект в CPython участвует в cycle GC. Но если объект GC-tracked, перед его PyObject в памяти размещается дополнительный служебный заголовок.

Этот заголовок используется сборщиком мусора и в исходниках gc.c фигурирует как часть внутренних структур GC. В частности, коллектор работает с указателями PyGCHead_PREV, PyGCHead_NEXT, а также с набором внутренних флагов, хранящихся в GC-header.

На практике это означает, что в памяти такой объект выглядит примерно так:

[ GC header ][ PyObject ][ payload ]

Сначала располагается служебная часть, используемая сборщиком мусора, затем стандартный заголовок PyObject, а уже после него – данные конкретного типа (payload).

Важно понимать один момент: GC-header присутствует не у всех объектов. Он добавляется только для тех типов, которые поддерживают cyclic garbage collection.

Поколения как doubly linked lists

Внутри сборщика мусора tracked объекты хранятся не в каком-то абстрактном «глобальном наборе», а в двусвязных списках поколений.

Если посмотреть исходники gc.c, можно увидеть операции типа:

  • gc_list_append

  • gc_list_remove

  • gc_list_move

  • gc_list_merge

Там же определены структуры для разных поколений: young, old[...] и permanent_generation.

Это важная деталь реализации. Она объясняет, почему стоимость работы GC зависит прежде всего от количества tracked container objects и от того, сколько из них попадает в конкретное поколение.

Иными словами, сборщик мусора итерируется не по «всей памяти процесса» и не по каждому байту. Он проходит только по связанным спискам объектов, которые объявлены GC-aware.

Какие объекты вообще может отслеживать GC

Чтобы объектный тип мог участвовать в cycle GC, его type object должен выставить флаг Py_TPFLAGS_HAVE_GC и реализовать функцию tp_traverse.

Через tp_traverse сборщик мусора получает возможность обходить все ссылки, которые объект хранит на другие Python-объекты. Это необходимо, чтобы GC мог обнаруживать циклические графы.

Если тип изменяемый (mutable) и его внутренние ссылки можно очищать для разрыва циклов, обычно также реализуют функцию tp_clear. Она используется для того, чтобы GC мог обнулить ссылки между объектами и тем самым разорвать цикл перед деаллокацией.

Кроме того, конструктор такого типа должен:

  1. аллоцировать объект через специальные GC-aware функции (например PyObject_GC_New);

  2. после инициализации всех ссылочных полей вызвать PyObject_GC_Track, чтобы зарегистрировать объект в структурах сборщика мусора.

Из этого следует довольно простой, но важный вывод: GC в CPython кооперативный.

Сборщик мусора не может сам понять внутреннюю структуру произвольного объекта из C-расширения. Поэтому тип должен явно «научить» GC, как обходить свои ссылки и как их очищать при необходимости.

tp_traverse: главный контракт с collector'ом

Функция tp_traverse(self, visit, arg) – это callback, через который тип сообщает сборщику мусора, на какие другие Python-объекты он ссылается.

В документации по cyclic GC support написано, что core Python использует visitor functions для обнаружения циклического мусора. В исходниках gc.c это отражено буквально: коллектор вызывает tp_traverse на фазах анализа ссылок и определения достижимости объектов.

Типичный шаблон реализации на C выглядит так:

static int my_traverse(MyObj *self, visitproc visit, void *arg) {
  Py_VISIT(self->field1);
  Py_VISIT(self->field2);
  return 0;
}

Макрос Py_VISIT сообщает GC: «этот объект содержит ссылку на другой Python-объект».

Если extension-тип реализует tp_traverse неправильно, сборщик мусора может:

  • не увидеть ребро в графе ссылок;

  • не собрать циклический мусор;

  • или, в худшем случае, привести структуру объектов к неконсистентному состоянию.

Поэтому вопросы про tp_traverse и tp_clear на технических интервью – это на самом деле проверка понимания внутренних механизмов CPython, а не просто знание терминов.

Как GC ищет циклический мусор

Один из самых интересных моментов в реализации CPython: сборщик мусора не строит отдельный глобальный граф объектов.

Вместо этого он работает со списком кандидатов и использует служебные поля в GC header как временное хранилище данных.

Если посмотреть исходники gc.c, ключевые шаги алгоритма хорошо видны через функции и комментарии:

  • update_refs()

  • subtract_refs()

  • move_unreachable()

Алгоритм в общих чертах выглядит так:

  1. Сначала collector копирует настоящий refcount объекта в служебное поле gc_refs.

  2. Затем из этого значения вычитаются внутренние ссылки между объектами внутри анализируемого множества.

  3. После этого становится понятно, какие объекты имеют внешние входящие ссылки, а какие – нет.

Объекты, которые остаются без внешней достижимости, считаются unreachable cyclic garbage.

Упрощённый псевдокод, который часто приводят на интервью, выглядит примерно так:

candidates = tracked objects in generation

for obj in candidates:
  gc_refs[obj] = real_refcount(obj)

for obj in candidates:
  for each child referenced via tp_traverse:
    if child in candidates:
      gc_refs[child] -= 1

reachable = objects with gc_refs > 0
unreachable = candidates - reachable

пройти транзитивно от reachable
все, что осталось в unreachable, – кандидаты на удаление

Ключевая идея алгоритма такая:

После вычитания внутренних ссылок gc_refs показывает не общее количество ссылок на объект, а число ссылок, приходящих извне анализируемого подграфа.

Если таких ссылок нет, а сам объект и его окружение недостижимы извне, значит перед нами мусорный цикл.

Именно это и описано в комментариях gc.c: после выполнения subtract_refs() объекты с положительным значением gc_refs считаются reachable from outside, а остальные становятся кандидатами на удаление.

Какие объекты участвуют в GC, а какие нет

Tracked container objects

Cycle GC занимается не всеми объектами Python, а в первую очередь container objects, способными хранить ссылки на другие объекты и потенциально образовывать циклы. В документации по support cyclic GC сказано: типы, которые не хранят ссылки на другие объекты или хранят ссылки только на «атомарные» объекты вроде чисел и строк, обычно не обязаны поддерживать GC explicitly.

Обычно в GC участвуют:

  • list

  • dict

  • set

  • экземпляры пользовательских классов

  • многие внутренние runtime-объекты

  • корректно реализованные extension-типы с Py_TPFLAGS_HAVE_GC.

Какие объекты не трекаются сборщиком мусора

Через gc.is_tracked() можно увидеть интересную деталь реализации, что простые атомарные объекты вроде 0 и "a" обычно не являются GC-tracked.

Более того, даже некоторые контейнеры могут временно не отслеживаться сборщиком мусора. В простых случаях CPython применяет оптимизации, чтобы уменьшить overhead GC. Поэтому нельзя утверждать, что dict или list всегда трекаются одинаково – всё зависит от того, какие объекты они содержат.

Это приводит к полезному interview-trick. Если тебя спрашивают, почему какой-то объект не появляется в результате gc.get_objects(), причина может быть не только в том, что объект уже уничтожен. Возможно, он вообще не отслеживается сборщиком мусора.

Документация модуля gc предупреждает об этом: функции вроде get_objects(), get_referrers() и другие работают только с объектами, поддерживающими cyclic GC.

Объекты из C-расширений, которые не реализуют поддержку GC, в этих списках просто не появятся.

Особые случаи: del, финализаторы, uncollectable garbage, weakref

Что не так с del

Олдовый ответ «цикл с __del__ не собирается» сегодня уже недостаточно точен. В современной документации модуля gc сказано, что начиная с Python 3.4 объекты с __del__() больше не оказываются автоматически в gc.garbage просто из-за наличия finalizer. Это следствие более безопасной модели финализации в CPython. Поэтому корректный ответ сегодня такой: исторически это была большая проблема, но в современном CPython наличие __del__ само по себе не означает автоматический uncollectable cycle.

Финализация и resurrection

В документации по type objects отдельно оговаривается один важный момент: финализатор может "воскресить" объект (resurrection), то есть снова сделать его достижимым из программы.

Если это происходит, уничтожение объекта может быть отменено. Это один из самых неприятных edge cases, когда пытаешься рассуждать о жизненном цикле объектов.

Простой пример:

saved = None

class Lazarus:
  def __del__(self):
    global saved
    saved = self
    
obj = Lazarus()
del obj

После вызова __del__ объект снова становится достижим через saved.

На технических интервью этот пример часто используют, чтобы показать важный нюанс: финализация – это не просто последний print перед освобождением памяти.

На самом деле финализатор может изменить reachability граф объектов, и из-за этого объект может продолжить жить дальше.

gc.garbage и uncollectable objects

В современном CPython gc.garbage в норме должен быть пустым или почти пустым. Документация gc отмечает, что после улучшений модели финализации туда обычно попадают только специфические случаи, например проблемные C extension types или сценарии с DEBUG_SAVEALL. Поэтому ненулевой gc.garbage в production – это повод смотреть на пользовательские extension types, экзотические финализаторы и отладочные настройки.

weakref

Модуль weakref существует именно для ситуаций, когда тебе нужно ссылаться на объект, но не продлевать его lifetime. Документация говорит: weak reference не удерживает объект живым. Поэтому WeakValueDictionary, WeakKeyDictionary и WeakSet полезны для кэшей, registries, observer lists и вспомогательных индексов, которые не должны становиться причиной memory retention.

Простой production-паттерн:

import weakref

cache = weakref.WeakValueDictionary()

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

Stop-the-world поведение и влияние на backend latency

Cycle GC в CPython не похож на большие параллельные tracing collector из JVM. Во время проходов collector обходит tracked objects, вызывает tp_traverse, меняет состояние служебных списков и работает в специальном режиме интерпретатора. Для Python-кода это означает паузу на время шага коллекции. В Python 3.14 collector стал incremental, и в блоке What's New сказано, что это уменьшает максимальные pause times на больших heap на порядок и больше.

С практической точки зрения это значит:

  • в CPU-bound сервисах GC может вносить вклад в p95/p99 latency;

  • в churn-heavy workload с большим количеством контейнеров могут появляться редкие паузы;

  • уменьшение worst-case pause time было одной из причин redesign collector'а в 3.14.

В CPython основная стоимость по времени обычно не в refcount, а в обходе tracked object graphs циклическим GC. На больших heap и в long-running сервисах это может проявляться как latency spikes, поэтому новый incremental collector в 3.14 – важное изменение именно для production latency.

Производительность: когда GC становится bottleneck

Стоимость cycle GC складывается из нескольких компонентов: нужно пройти по спискам tracked объектов, вызывать tp_traverse, вычитать внутренние ссылки, определять unreachable группы, вызывать финализацию и очищать ссылки у собираемых объектов. По исходникам gc.c видно, что collector – это не одна магическая функция, а серия проходов по контейнерам и служебным спискам.

Практически bottleneck возникает, когда:

  • процесс долго живет и накопил большой old heap;

  • код создает много временных контейнеров;

  • object graph сложные и часто содержат циклы;

  • есть retention через caches, globals, registries, closures;

  • есть extension-модули, которые вмешиваются в lifetime объектов или аллоцируют native memory мимо Python heap.

Типичные backend-паттерны, создающие memory pressure:

# 1. Глобальный кэш без eviction
GLOBAL_CACHE = {}

# 2. Замыкание держит тяжелый объект
def make_handler(big_obj):
  def handler():
    return big_obj
  return handler
  
  # 3. Циклы через ORM/backrefs/state
  class Node:
    def __init__(self):
      self.parent = None
      self.children = []

Сами по себе эти примеры не гарантируют leak, но именно такие конструкции часто становятся причиной долгоживущих графов, которые либо удерживаются логикой приложения, либо сложны для анализа при отладке.

Диагностика memory leak в Python-процессе

Что умеет gc

Модуль gc предоставляет базовый набор инструментов для диагностики работы сборщика мусора. Среди наиболее полезных функций:

  • gc.get_objects()

  • gc.get_referrers()

  • gc.get_referents()

  • gc.get_stats()

  • gc.set_debug()

  • gc.is_tracked()

При этом документация отдельно предупреждает: функция get_referrers() предназначена в первую очередь для отладки. Она может возвращать объекты, находящиеся во временно неконсистентном состоянии, поэтому полагаться на её результат в prod-коде не стоит.

Есть и более важное ограничение. Все эти инструменты работают только с GC-tracked объектами.

Если утечка памяти происходит внутри нативной библиотеки или в C-extension, который не поддерживает GC, то gc.get_objects() просто не покажет эти объекты. В таких случаях модуль gc не даёт полной картины, и для диагностики приходится использовать другие инструменты профилирования памяти.

Базовая диагностика утечек памяти через модуль gc может выглядеть примерно так:

import gc
from collections import Counter

gc.collect()
cnt = Counter(type(o).__name__ for o in gc.get_objects())
print(cnt.most_common(20))

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

После этого можно попробовать найти конкретные экземпляры:

suspects = [o for o in gc.get_objects() if type(o).__name__ == "MyHeavyObject"]
obj = suspects[0]
print(gc.get_referrers(obj)[:5])

Функция gc.get_referrers() позволяет посмотреть, какие объекты продолжают удерживать ссылки на интересующий нас объект.

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

tracemalloc

Для long-running сервисов один из лучших инструментов – tracemalloc. Документация рекомендует запускать его как можно раньше, через PYTHONTRACEMALLOC=1 или -X tracemalloc, чтобы не потерять ранние аллокации. Он умеет делать snapshots и сравнивать их по месту аллокации. Это сильно полезнее, чем просто смотреть на RSS без привязки к коду.

Типичный сценарий:

import tracemalloc

tracemalloc.start(25)

snap1 = tracemalloc.take_snapshot()
# прогоняем нагрузку
snap2 = tracemalloc.take_snapshot()

for stat in snap2.compare_to(snap1, "lineno")[:20]:
  print(stat)

Важно помнить: tracemalloc показывает Python allocations, а не всю native memory процесса. Поэтому при росте RSS и спокойном tracemalloc стоит смотреть в сторону extension-модулей, аллокаторов и внешних библиотек. Документация по Python memory management тоже подчеркивает, что Python управляет своим private heap отдельно и что смешивание allocators может приводить к тяжелым проблемам.

objgraph

Это уже сторонний инструмент, но очень полезный для построения backrefs и поиска цепочек удержания. Для собеседования достаточно знать, что objgraph помогает ответить на вопрос «почему объект все еще жив», визуализируя ссылки до корней удержания. При этом формальная опора в официальной документации будет на gc.get_referrers() и диагностику через tracked objects, а objgraph можно упомянуть как практическое дополнение.

Prod практики: что реально делают в сервисах

Когда отключают GC

Иногда cycle GC временно отключают на горячих участках кода (hot paths), где почти не возникает циклических ссылок, но создаётся большое количество короткоживущих объектов. В таких местах может быть важна предсказуемая latency, и дополнительная работа сборщика мусора становится нежелательной.

В этом режиме продолжает работать только reference counting, а циклический сборщик мусора не запускается.

Однако цена такого решения очевидна: циклические структуры не будут собираться, пока GC снова не включат. Поэтому подход вида «давайте просто отключим GC в проде» без измерений и профилирования – плохая практика.

Управление сборщиком через модуль gc официально поддерживается, но тюнинг без метрик почти всегда приводит к ухудшению ситуации.

Типичный шаблон выглядит так:

import gc

gc.disable()
try:
  run_hot_batch()
finally:
  gc.enable()

Тюнинг thresholds

Смысл настройки параметров GC – найти баланс между частотой сборок и размером heap/длительностью пауз.

Если threshold0 слишком низкий, сборки мусора будут происходить слишком часто.
Если он слишком высокий – в поколениях (young и old) может накапливаться больше мусора: сборки будут происходить реже, но каждая из них станет тяжелее.

В Python 3.14 важно помнить ещё одну деталь реализации:

  • threshold2 больше не используется и фактически игнорируется;

  • threshold1 определяет, какую долю old generation сканировать за один запуск GC.

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

fork() и gc.freeze()

Здесь вопрос с подвохом. В документации gc есть специальная рекомендация для fork() без exec(): до форка можно отключить GC и вызвать gc.freeze(), чтобы минимизировать unnecessary copy-on-write в дочерних процессах; потом в child collector включается обратно. Для pre-fork воркеров и серверов это вполне практическая optimization technique.

Что делать в FastAPI / Celery / long-running worker

Если растет память в долго живущем процессе, план обычно такой:

  1. посмотреть графики RSS и скорость роста;

  2. включить tracemalloc как можно раньше;

  3. периодически снимать gc.get_stats() и размер tracked heap через gc.get_objects();

  4. искать растущие типы и их referrers;

  5. отдельно проверять native memory и C extensions;

  6. смотреть на globals, singleton registries, LRU/cache, background tasks, middleware state, closures, ORM session graphs.

Самый важный инсайт: утечка памяти в Python очень часто означает не поломку коллектора, а то, что приложение само продолжает удерживать сильные ссылки дольше, чем предполагает разработчик.

Частые tricky-вопросы на senior interview

Почему Python может течь по памяти, даже если GC есть

Потому что GC не всемогущ. Он не удаляет объекты, которые все еще достижимы. Если их удерживают globals, caches, registries, closures, очереди, фоновые задачи или long-lived graphs, это retention bug, а не bug сборщика. Кроме того, часть памяти может жить вне Python heap, а часть объектов может не поддерживать GC.

Чем GC в Python отличается от Java

В CPython основной механизм управления памятью – reference counting.
Cyclic GC лишь дополняет его и используется для обнаружения циклических ссылок.

В JVM основной механизм – tracing GC, который проходит по графу достижимости, начиная от root set.

Отсюда возникает важное различие:

  • в CPython освобождение многих объектов выглядит почти немедленным

  • в Java уничтожение объектов менее детерминировано по времени

Это одно из самых фундаментальных концептуальных различий между двумя экосистемами.

Что происходит, если есть цикл с __del__

Исторически это был источник uncollectable garbage. В современном CPython после изменений модели финализации наличие __del__ само по себе не означает, что цикл не соберется. Но финализаторы и resurrection все еще делают reasoning сложным, а проблемные C-level finalizers могут приводить к плохим кейсам.

Может ли refcount стать отрицательным

В корректной работе интерпретатора и корректных extension-модулей – нет. Если это происходит, речь уже не о «сложности Python GC», а о memory corruption, broken INCREF/DECREF balance или ошибке в native коде. Документация по memory management прямо предупреждает, что неправильное смешивание allocators и нарушения протокола владения ссылками могут иметь фатальные последствия.

Что происходит при fork

После fork() дочерний процесс получает memory image родителя через механизм copy-on-write.

Пока память не изменяется, она фактически разделяется между процессами, но любые изменения в heap ломают это разделение.

Поэтому в документации gc есть рекомендации:

  • использовать gc.freeze()

  • временно отключать GC перед fork()

Это особенно актуально для pre-fork моделей (например, в серверных приложениях).

Как взаимодействуют GC и C extensions

Если extension type хранит ссылки на Python-объекты и может участвовать в циклах, он обязан корректно реализовать GC protocol: Py_TPFLAGS_HAVE_GC, tp_traverse, а для mutable types и tp_clear. Также важен правильный порядок деаллокации и UnTrack. Ошибки в этих местах приводят к утечкам, висячим ссылкам, неконсистентным GC спискам и падениям в seemingly innocent gc.collect().

Общие итоги

В CPython управление памятью в первую очередь основано на reference counting.
У каждого объекта в заголовке хранятся два ключевых поля: ob_refcnt и ob_type.

Когда появляется новый владелец ссылки, refcount увеличивается; когда ссылка исчезает – уменьшается. Когда счётчик становится равен нулю, CPython обычно немедленно вызывает деаллокатор типа и освобождает объект.

Однако одного reference counting недостаточно из-за циклических ссылок. Поэтому поверх него работает cyclic garbage collector.

Этот сборщик мусора работает только с tracked container objects, которые поддерживают GC-протокол через:

  • Py_TPFLAGS_HAVE_GC

  • tp_traverse

  • иногда tp_clear

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

Исторически сборщик мусора был трёхпоколенческим, но в Python 3.14+ он стал incremental, а модель generation 1 была удалена.

На практике проблемы с памятью в Python чаще связаны не с самим GC, а с другими причинами:

  • object retention (глобальные структуры, кэши, очереди и долгоживущие графы объектов)

  • ошибки в C extensions

  • native allocations за пределами Python heap.

Поэтому в реальных сервисах диагностика проблем памяти обычно начинается не с вопроса «почему GC не работает», а с вопроса «кто продолжает удерживать объект».