Как Python управляет памятью и сборкой мусора?

Question

Accepted Answer

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

## Подсчет ссылок — основной механизм

```python
import sys

x = [1, 2, 3]        # the list object has refcount 1
y = x                 # refcount 2 (another name references it)
sys.getrefcount(x)    # shows the count (slightly higher due to the call itself)

del y                 # refcount 1
del x                 # refcount 0 → the object is FREED immediately
```

Каждый объект отслеживает, сколько ссылок на него указывают. Когда счетчик падает до **нуля**, память освобождается **немедленно**. Это детерминированно и оперативно — объекты удаляются, как только на них ничто не ссылается.

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

```python
# reference counting alone can't free this:
a = {}
b = {}
a["b"] = b      # a references b
b["a"] = a      # b references a → they reference EACH OTHER
del a, b        # the names are gone, but the objects still reference each other
# → refcounts never reach 0 → they'd leak with refcounting alone
```

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

## Циклический сборщик мусора

```python
import gc

# the generational GC periodically finds and frees unreachable CYCLES
gc.collect()        # manually trigger a collection
gc.get_count()      # objects tracked per generation
```

**Поколенческий сборщик мусора** Python периодически обнаруживает и освобождает эти недостижимые циклы. Он *поколенческий* — более новые объекты проверяются чаще (большинство объектов живут недолго), что эффективно.

## Практические последствия и источники утечек

```text
✓ Most memory is reclaimed promptly via reference counting
⚠️ Leaks still happen from REACHABLE references that outlive their usefulness:
   - global caches/lists that only grow
   - objects held by long-lived closures or class attributes
   - registered callbacks/listeners never removed
```

Сборщик мусора обрабатывает циклы, но не может освободить объекты, которые остаются *достижимыми* — типичная в реальном мире "утечка" — это непреднамеренное сохранение ссылок (например, постоянно растущий глобальный кэш).

## Другие детали

```text
- Small integers (-5..256) and short strings are CACHED/interned (shared, reused)
- CPython uses memory pools (pymalloc) for small objects (efficiency)
```

## Почему это важно

Понимание модели памяти Python — оперативный подсчет ссылок плюс циклический сборщик мусора — объясняет реальное поведение: почему объекты обычно освобождаются немедленно, почему циклические ссылки нуждаются в сборщике мусора, и, что критично, почему "утечки памяти" в Python происходят из *достижимых* ссылок (растущих кэшей, задержанных замыканий, удаленных обратных вызовов) а не забытых освобождений.

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