Python Garbage Collection: Reference Counting + Cycle Collector

Python's GC is a two-layer system. The primary layer is reference counting — every CPython object has a refcount field in its C struct, and every reference operation increments or decrements it. When the count reaches zero, the object is deallocated immediately, tp_dealloc is called, destructors run, and memory goes back to the allocator. This is fundamentally different from the JVM — most Python object cleanup is deterministic and synchronous, no waiting for a GC cycle. The downside: reference counting is per-op overhead on every assignment and function call, which is one reason CPython is slower than a JIT'd JVM. The other downside is reference counting cannot collect cycles. If object a holds a reference to b and b holds a reference to a, their refcounts include each other, so neither will ever hit zero even if nothing external points to them. Python solves this with a secondary generational cycle collector in the gc module. It periodically scans container objects — lists, dicts, classes, etc., anything that could hold references — and uses a mark-and-sweep-style algorithm to find unreachable cycles and free them. There are three generations. Newly allocated containers go into gen 0; objects that survive a collection are promoted to gen 1; surviving gen 1 survivors promote to gen 2. Higher generations are scanned less frequently, based on the assumption that long-lived objects are less likely to be garbage. Collection triggers when allocations minus deallocations cross a threshold — default is (700, 10, 10), meaning gen 0 runs after 700 net allocations, gen 1 runs every 10 gen-0 runs, and so on. It's not time-based — purely allocation-pressure driven. Practical implications: gc.collect() forces a full collection, useful before memory-sensitive operations. gc.disable() is sometimes used in performance-critical hot loops to avoid unpredictable pauses, with an explicit gc.collect() later. For "logical cycles" you know about in advance — common in parent-child object graphs like DOM trees or tree data structures — use weakref.ref or weakref.proxy to avoid creating the cycle at all, letting reference counting reclaim the objects deterministically.