Общая модель памяти

В большинстве реализаций Python (особенно CPython) управление памятью строится вокруг нескольких идей:

1. Объекты создаются в куче (heap), а переменные хранят ссылки на них

2. Основной механизм освобождения — подсчёт ссылок (reference counting)

3. Дополнительный механизм — сборщик циклов (garbage collector для cyclic references)

4. Выделение мелких блоков оптимизировано собственным аллокатором

Подсчёт ссылок (reference counting)

Каждый объект в CPython имеет счётчик ссылок: сколько «ссылок» на него существует. Примеры, которые увеличивают счётчик:

• присваивание переменной

• добавление объекта в список/словарь

• передача в функцию (временно)

Когда счётчик становится равен нулю, объект может быть уничтожен сразу же.

Пример логики:

a = []
b = a      # +1 ссылка
del a      # -1 ссылка, но b всё ещё держит объект
del b      # теперь ссылок 0, объект можно освободить

Проблема циклических ссылок

Подсчёт ссылок не справляется с циклами: объекты могут ссылаться друг на друга и не обнулять счётчик.

a = []
a.append(a)  # список содержит ссылку на самого себя (цикл)

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

Аллокатор Python и “почему память не вернулась ОС”

Даже когда объекты уничтожены, Python может:

• оставить освобождённые блоки в своих пулах

• переиспользовать их для новых объектов

• не отдавать память операционной системе немедленно

Это часто выглядит как “память растёт и не падает”, но на деле процесс просто держит резерв, чтобы быстрее обслуживать будущие аллокации.

Практические следствия для разработчика

На базовом уровне важно помнить:

1. Удаление переменной (del) удаляет ссылку, а не обязательно объект

2. Циклы могут требовать участия GC

3. Пики памяти могут не исчезать сразу из метрик ОС

4. Большие структуры лучше освобождать, убирая ссылки и избегая циклов там, где это возможно

Вывод

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