Вопрос проверяет понимание работы сборщика мусора в Python и типичных проблем с управлением памятью.
В Python используется сборщик мусора с поколениями. Объекты делятся на молодые и старые в зависимости от времени жизни. Молодые объекты проверяются чаще, старые — реже. Это ускоряет работу GC. Проблемы возникают при утечках памяти и циклических ссылках.
Сборка мусора в Python устроена не примитивно и оптимизирована под реальные сценарии.
Поколения GC — это механизм, который делит объекты по «возрасту».
В CPython есть:
поколение 0 — новые объекты
поколение 1 — объекты, пережившие несколько сборок
поколение 2 — долгоживущие объекты
Идея простая: большинство объектов живут недолго.
GC:
Часто проверяет поколение 0
Реже проверяет поколение 1
Очень редко — поколение 2
Если объект «выжил», он переходит в старшее поколение.
На практике встречаются:
циклические ссылки
рост памяти при кэшировании
удержание объектов глобальными структурами
утечки из-за ссылок в замыканиях
GC не всегда может освободить память сразу.
GC не управляет:
памятью расширений на C
системными ресурсами напрямую
В таких случаях важно явно освобождать ресурсы.
Поколения GC ускоряют сборку мусора, но не защищают от логических утечек памяти. За жизненным циклом объектов всё равно нужно следить.
