Hur hanterar Python minne och skräpinsamling?

Question

Accepted Answer

Python hanterar minne **automatiskt** med två mekanismer: **referensräkning** (den primära metoden) plus en **cyklisk skräpsamlare** som hanterar referenscykler. Du behöver aldrig frigöra minne manuellt, men att förstå hur det fungerar förklarar minnesbeteende och läckor.

## Referensräkning — den primära mekanismen

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

Varje objekt spårar hur många referenser som pekar på det. När räkningen sjunker till **noll** frigörs minnet **omedelbar**. Detta är deterministiskt och snabbt — objekt tas bort så fort ingenting refererar till dem.

## Problemet: referenscykler

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

Två objekt som refererar till varandra håller varandras refcount över noll även när de är oåtkomliga — en cykel som ren referensräkning inte kan samla in.

## Den cykliska skräpsamlaren

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

Pythons kompletterande **generationell skräpsamlare** detekterar och frigör dessa oåtkomliga cykler periodiskt. Den är *generationell* — nyare objekt kontrolleras oftare (de flesta objekt dör ung), vilket är effektivt.

## Praktiska konsekvenser och läckkällor

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

Skräpsamlaren hanterar cykler, men kan inte frigöra objekt som fortfarande är *åtkomliga* — den vanliga verkliga "läckan" är att oavsiktligt hålla referenser levande (t.ex. en ständigt växande global cache).

## Övriga detaljer

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

## Varför det spelar roll

Att förstå Pythons minnesmodell — snabb referensräkning plus en cyklisk GC — förklarar verkligt beteende: varför objekt vanligtvis frigörs omedelbar, varför referenscykler behöver GC:n, och kritiskt varför "minnesläckor" i Python kommer från *åtkomliga* referenser (växande caches, kvarstående closures, borttagna callbacks) snarare än glömda frigörelser.

Denna kunskap är väsentlig för att diagnostisera minnestillväxt i långkörande tjänster och för att skriva minneskonsekvent kod — att veta att lösningen vanligtvis är att bryta referenser (begränsa caches, rensa registreringar) snarare än något GC:n kan göra för dig.