Jak Python zarządza pamięcią i garbage collection?

Question

Accepted Answer

Python zarządza pamięcią **automatycznie** za pomocą dwóch mechanizmów: **liczania referencji** (metoda podstawowa) oraz **cyklicznego garbage collectora**, który obsługuje cykle referencji. Nigdy nie musisz ręcznie zwalniać pamięci, ale zrozumienie, jak to działa, wyjaśnia zachowanie pamięci i przecieki.

## Liczanie referencji — mechanizm podstawowy

```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
```

Każdy obiekt śledzi, ile referencji do niego wskazuje. Gdy liczba spadnie do **zera**, pamięć jest zwalniana **natychmiast**. To jest deterministyczne i szybkie — obiekty umierają, gdy nic ich nie referuje.

## Problem: cykle referencji

```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
```

Dwa obiekty referujące się nawzajem utrzymują liczniki referencji powyżej zera, nawet gdy są niedostępne — cykl, którego czyste liczanie referencji nie może zebrać.

## Cykliczny garbage collector

```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
```

**Generacyjny garbage collector** Python'a okresowo wykrywa i zwalnia te niedostępne cykle. Jest *generacyjny* — nowsze obiekty są sprawdzane częściej (większość obiektów żyje krótko), co jest efektywne.

## Praktyczne implikacje i źródła przecieków

```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
```

GC obsługuje cykle, ale nie może zwolnić obiektów, które są nadal *osiągalne* — typowy rzeczywisty "przeciek" to niezamierzone utrzymywanie referencji (np. stale rosnący globalny cache).

## Inne szczegóły

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

## Dlaczego to ważne

Zrozumienie modelu pamięci Python'a — szybkie liczanie referencji plus cykliczny GC — wyjaśnia rzeczywiste zachowania: dlaczego obiekty są zwykle zwalniane natychmiast, dlaczego cykle referencji potrzebują GC, i co kluczowe, dlaczego "przecieki pamięci" w Python'ie pochodzą z *osiągalnych* referencji (rosnące cache'e, pozostające domknięcia, niekasowane callbacki) a nie z zapomnianych zwolnień.

Ta wiedza jest niezbędna do diagnozowania wzrostu pamięci w długo działających usługach i do pisania kodu świadomego pamięci — wiedząc, że rozwiązaniem jest zwykle przerwanie referencji (ograniczanie cache'ów, czyszczenie rejestracji) zamiast czegoś, co GC może dla Ciebie zrobić.