How does Python manage memory and garbage collection?

Question

Accepted Answer

Python manages memory **automatically** using two mechanisms: **reference counting** (the primary method) plus a **cyclic garbage collector** that handles reference cycles. You never manually free memory, but understanding how it works explains memory behavior and leaks.

## Reference counting — the primary mechanism

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

Every object tracks how many references point to it. When the count drops to **zero**, the memory is freed **immediately**. This is deterministic and prompt — objects die as soon as nothing references them.

## The problem: reference cycles

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

Two objects referencing each other keep each other's refcount above zero even when unreachable — a cycle that pure reference counting can't collect.

## The cyclic 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
```

Python's supplemental **generational garbage collector** periodically detects and frees these unreachable cycles. It's *generational* — newer objects are checked more often (most objects die young), which is efficient.

## Practical implications & leak sources

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

The GC handles cycles, but it can't free objects that are still *reachable* — the common real-world "leak" is unintentionally keeping references alive (e.g. an ever-growing global cache).

## Other details

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

## Why it matters

Understanding Python's memory model — prompt reference counting plus a cyclic GC — explains real behaviors: why objects are usually freed immediately, why reference cycles need the GC, and crucially why "memory leaks" in Python come from *reachable* references (growing caches, lingering closures, un-removed callbacks) rather than forgotten frees.

This knowledge is essential for diagnosing memory growth in long-running services and for writing memory-conscious code — knowing that the fix is usually breaking references (bounding caches, cleaning up registrations) rather than anything the GC can do for you.