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

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

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

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

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

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

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

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

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

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

Минимальный пример:

import weakref

class Session:
    pass

session = Session()
watch = weakref.ref(session)
print(watch() is session)  # True

del session
print(watch())            # None

Вызов watch() временно возвращает сильную ссылку на объект, если он ещё жив. Между проверкой результата и использованием объекта возможны изменения в многопоточном коде, поэтому обычно результат сохраняют в локальную переменную и работают именно с ней.

Слабые ссылки поддерживаются не всеми объектами. Конкретный класс должен предоставлять необходимую поддержку weak references; например, некоторые встроенные типы, включая list и dict, напрямую не допускают слабые ссылки. Для собственных классов обычный экземпляр обычно поддерживает их, если это не ограничено специальной структурой атрибутов.

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

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

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

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

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

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

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

1. Может ли слабая ссылка гарантировать, что объект останется жив до следующей строки программы?

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

2. Чем слабая ссылка отличается от удаления объекта сборщиком мусора?

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

3. Почему слабые ссылки не подходят для хранения важных данных приложения?

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