Hoe beheert Python geheugen en garbage collection?

Question

Accepted Answer

Python beheert geheugen **automatisch** met behulp van twee mechanismes: **reference counting** (de primaire methode) plus een **cyclische garbage collector** die referentiecycli afhandelt. U hoeft geheugen nooit handmatig vrij te geven, maar het begrijpen hoe het werkt verklaart geheugengedrag en leaks.

## Referentietelling — het primaire mechanisme

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

Elk object houdt bij hoeveel referenties naar het wijzen. Wanneer het aantal naar **nul** daalt, wordt het geheugen **onmiddellijk** vrijgegeven. Dit is deterministisch en snel — objecten verdwijnen zodra niets meer naar hen verwijst.

## Het probleem: referentiecycli

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

Twee objecten die naar elkaar verwijzen houden elkaars refcount boven nul, zelfs wanneer ze onbereikbaar zijn — een cyclus die zuivere referentietelling niet kan verzamelen.

## De cyclische 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
```

De aanvullende **generationele garbage collector** van Python detecteert en geeft deze onbereikbare cycli periodiek vrij. Het is *generationeel* — nieuwere objecten worden vaker gecontroleerd (de meeste objecten zijn kort leefde), wat efficiënt is.

## Praktische implicaties & leakbronnen

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

De GC handelt cycli af, maar kan objecten die nog steeds *bereikbaar* zijn niet vrijgeven — de veel voorkomende praktische "leak" is dat u referenties onopzettelijk in leven houdt (bijv. een steeds groter wordende globale cache).

## Overige details

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

## Waarom het belangrijk is

Het begrijpen van Pythons geheugenmodel — snelle referentietelling plus een cyclische GC — verklaart werkelijk gedrag: waarom objecten meestal onmiddellijk worden vrijgegeven, waarom referentiecycli de GC nodig hebben, en cruciaal waarom "geheugenleaks" in Python afkomstig zijn van *bereikbare* referenties (groeiende caches, overblijvende closures, verwijderde callbacks) in plaats van vergeten vrij te geven.

Deze kennis is essentieel voor het diagnosticeren van geheugengroei in langdurige services en voor het schrijven van geheugenefficiënte code — wetende dat de oplossing meestal het onderbreken van referenties is (het beperken van caches, het opruimen van registraties) in plaats van iets wat de GC voor u kan doen.