Сталкивался ли с утечками памяти?

Что проверяют

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

Как отвечать

Начните с механики: основной способ это подсчёт ссылок, плюс отдельный сборщик для циклов. Настоящая утечка на уровне C-расширения редка, обычная причина роста это объекты, которые кто-то продолжает держать:

• глобальные словари и самодельные кэши без ограничения размера;
• functools.lru_cache на методе: кэш держит self, а вместе с ним весь объект;
• списки-накопители, очереди без потолка, подписчики и колбэки, которые никто не отписывает;
• ссылка на фрейм из сохранённого исключения и замыкание, захватившее тяжёлый объект.

Инструменты: tracemalloc со снимками и сравнением, objgraph для поиска обратных ссылок, счётчики объектов по типам через gc.get_objects, gc.garbage для несобираемых циклов. Лечение: ограниченные по размеру кэши, weakref, контекстные менеджеры, а как страховка перезапуск воркеров по лимиту обработанных запросов.

Где спотыкаются

Уверены, что сборщик мусора делает утечки невозможными. Он убирает недостижимое, а глобальный кэш достижим всегда и растёт ровно столько, сколько живёт процесс.

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

Отвечают историей про то, как нашли, оптимизировали и стало лучше, с придуманными цифрами выигрыша. Без названия инструмента и без гипотезы, что именно текло, такой рассказ читается как заготовка и обесценивает остальной ответ.