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

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

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

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

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

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

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

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

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

Для каждого вызова кэш формирует ключ из аргументов и сохраняет связь «ключ — результат». Аргументы должны быть хешируемыми, а сохранённые ключи и значения обычно удерживаются сильными ссылками. Поэтому крупный аргумент может оставаться в памяти вместе с результатом даже после того, как вызывающий код больше не хранит на него ссылку.

У lru_cache параметр maxsize ограничивает число записей. При достижении лимита новые результаты вытесняют давно не использовавшиеся, что ограничивает память самим кэшем, но не гарантирует малое потребление: одна запись всё ещё может быть очень большой.

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

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

Для диагностики полезны статистика попаданий и промахов кэша, оценка размера ключей и результатов, а также наблюдение за количеством уникальных входов. Если кэш используется в методе экземпляра, в ключ может попасть self; тогда кэш способен удерживать экземпляры, пока соответствующие записи не будут вытеснены или очищены.

from functools import lru_cache

@lru_cache(maxsize=1024)
def load_profile(user_id):
    return fetch_profile(user_id)

# Периодическая очистка при массовом изменении данных:
load_profile.cache_clear()

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

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

В API-сервисе мемоизировали получение настроек по идентификатору клиента. На тестовых данных число клиентов было небольшим, поэтому использовали неограниченный кэш. После запуска в production идентификаторы стали почти всегда уникальными, и память процесса росла до перезапуска.

Рассматривались три варианта. Полный отказ от кэша устранял рост памяти, но увеличивал нагрузку на базу данных. Периодический cache_clear был простым решением, однако сбрасывал и часто используемые записи, вызывая резкие всплески запросов. Ограниченный lru_cache с подходящим maxsize сохранял горячие данные и вытеснял холодные, поэтому выбрали его; для быстрого изменения настроек дополнительно выполняли очистку после массового обновления.

После решения память перестала зависеть от общего числа когда-либо встречавшихся клиентов и стала зависеть главным образом от верхней границы кэша и размера сохранённых результатов. Дополнительно проверили попадания и промахи, чтобы не получить большой кэш с малой практической пользой.

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

Почему работа сборщика мусора не освобождает записи кэша?

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

Достаточно ли ограничить количество записей, чтобы гарантировать безопасное потребление памяти?

Нет. Ограничение задаёт число записей, но не их суммарный размер. Тысяча результатов по несколько мегабайт всё ещё может занять гигабайты, а аргументы ключей также потребляют память. Для крупных значений нужен дополнительный контроль размера, TTL-кэш или внешний кэш с явной политикой хранения.

Почему кэширование метода может удерживать экземпляры объектов?

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