Ever wondered why you rarely have to manually free memory in Python, unlike in C or C++? That’s garbage collection at work quietly running in the background, cleaning up objects you no longer need. Understanding how it actually works helps you write faster code and catch subtle memory issues before they become real problems.<\/p>\n\n\n\n
Python’s garbage collection automatically frees memory by removing unused objects. Master Python internals and memory management with HCL GUVI\u2019s <\/em>Python Zero to Hero Course. <\/em><\/strong>Start your Python journey here<\/em><\/a><\/p>\n\n\n\n Garbage collection is Python’s automatic system for reclaiming memory from objects that are no longer needed. It works through two mechanisms: reference counting, which tracks how many references point to each object, and a generational garbage collector, which catches reference cycles that reference counting alone can’t detect.<\/p>\n\n\n\n In Python, every object even a simple integer has a reference count attached to it. This count increases whenever a new reference points to the object, and decreases whenever one is removed.<\/p>\n\n\n\n a = [1, 2, 3] b = a<\/strong><\/p>\n\n\n\n Here, both a and b point to the same list. The assignment doesn’t copy any data <\/a> it just adds a second reference to the same object in memory.<\/p>\n\n\n\n The moment an object’s reference count drops to zero, CPython immediately deallocates it. This happens through assignment, the del keyword, a variable going out of scope, or a container being deleted.<\/p>\n\n\n\n import sys<\/p>\n\n\n\n x = [1, 2, 3] print(sys.getrefcount(x)) # 2 one from x, one from getrefcount itself<\/strong><\/p>\n\n\n\n y = x print(sys.getrefcount(x)) # 3 now x and y both reference it<\/strong><\/p>\n\n\n\n y = None print(sys. getrefcount(x)) # back to 2<\/strong><\/p>\n\n\n\n sys.getrefcount() always reports one more than you’d expect, because passing the object into the function temporarily creates an extra reference of its own.<\/p>\n\n\n\n Reference counting is fast and predictable; an object is destroyed the instant it’s no longer needed, not at some unpredictable later point determined by a separate collector thread. <\/p>\n\n\n\n This immediacy is one of CPython’s defining design choices. It’s also part of why Python has historically needed the Global Interpreter Lock: updating a reference count safely across multiple threads requires some form of synchronization.<\/p>\n\n\n\n Reference counting has one fundamental blind spot: it cannot detect reference cycles, where two or more objects reference each other directly or indirectly.<\/p>\n\n\n\n x = [1, 2, 3] y = [4, 5, 6]<\/strong><\/p>\n\n\n\n x.append(y) y.append(x)<\/strong><\/p>\n\n\n\n Now x contains y, and y contains x. Even if nothing else in your program references either list, their reference counts never drop to zero each is still holding the other alive.<\/p>\n\n\n\n Without a second mechanism, these objects would simply leak, sitting in memory forever, even though your code can no longer reach them. <\/p>\n\n\n\n Reference cycles aren’t rare edge cases either; they show up naturally in linked lists, trees with parent pointers, and any object graph where two pieces of data need to know about each other. This is exactly the gap Python’s generational garbage collector exists to close.<\/p>\n\n\n\n Python’s cyclic garbage collector, accessible through the built-in gc module, organises every container object into one of three generations. Generation 0 holds newly created objects. Generation 1 holds objects that survived at least one collection round. Generation 2 holds long-lived objects that have survived multiple rounds.<\/p>\n\n\n\n This generational design is based on a simple observation: most objects die young. By checking generation 0 far more frequently than generation 2, Python avoids repeatedly re-scanning objects that have already proven they’re long-lived, which keeps collection overhead low.<\/p>\n\n\n\n Each generation has its own allocation counter and threshold. Every time a new container object is created, Python checks whether generation 0’s counter has exceeded its threshold. If it has, a collection cycle runs.<\/p>\n\n\n\n You can inspect and adjust these thresholds directly with gc.set_threshold(), tuning collection frequency for workloads with unusual allocation patterns.<\/p>\n\n\n\n Most of the time, you should let Python’s GC run on its own schedule. But you can manually trigger a full collection when needed:<\/p>\n\n\n\n import gc<\/strong><\/p>\n\n\n\n a = [1, 2, 3] del a gc.collect()<\/strong><\/p>\n\n\n\n This is occasionally useful right after a section of code <\/a>that creates a large number of temporary cyclic structures, where you want memory reclaimed immediately rather than waiting for the next automatic trigger.<\/p>\n\n\n\n You can disable automatic cyclic collection entirely:<\/p>\n\n\n\n import gc gc.disable()<\/strong><\/p>\n\n\n\n … performance-sensitive section …<\/strong><\/p>\n\n\n\n gc.enable()<\/strong><\/p>\n\n\n\n This is a real optimization technique in latency-sensitive applications, such as short-lived scripts, for instance, where the cyclic GC’s periodic pauses add overhead without ever paying off, since the whole process exits before cycles would matter anyway. Reference counting still runs regardless; disabling the GC only stops the cyclic-cycle scanner.<\/p>\n\n\n\n Python’s garbage collection automatically frees memory by removing unused objects. Master Python internals and memory management with HCL GUVI\u2019s <\/em>Python Zero to Hero Course. <\/em><\/strong>Start your Python journey here<\/em><\/a><\/p>\n\n\n\n The weakref module lets you reference an object without increasing its reference count. If the object is destroyed elsewhere, the weak reference simply returns None instead of keeping it alive artificially.<\/p>\n\n\n\n This is the standard fix for cycles that show up in graphs, trees with parent-pointers, or any structure where two objects naturally need to reference each other.<\/p>\n\n\n\nWhat Is Garbage Collection in Python?<\/strong><\/h2>\n\n\n\n
How Reference Counting Works<\/strong><\/h2>\n\n\n\n
\n
\n
\n
\n\n CPython<\/strong>, the reference implementation of Python, uses reference counting<\/strong> to destroy most objects as soon as their reference count reaches zero. However, objects involved in circular references<\/strong> cannot be reclaimed by reference counting alone. To handle these cases safely, CPython includes a separate cyclic garbage collector<\/strong> that periodically detects and removes unreachable groups of objects, helping prevent memory leaks in long-running applications.\n\n<\/div>\n\n\n\nThe Problem: Reference Cycles<\/strong><\/h2>\n\n\n\n
\n
\n
The Generational Garbage Collector<\/strong><\/h2>\n\n\n\n
\n
\n
import gc print(gc.get_threshold())\n\n(700, 10, 10) exact default can vary slightly by Python version<\/code><\/pre>\n\n\n\nHow the Algorithm Actually Finds Cycles<\/strong><\/h3>\n\n\n\n
\n
Manual Garbage Collection<\/strong><\/h2>\n\n\n\n
\n
\n
Reference Counting vs Generational GC<\/strong><\/h2>\n\n\n\n
Aspect<\/strong><\/td> Reference Counting<\/strong><\/td> Generational GC<\/strong><\/td><\/tr> Runs<\/td> Immediately, every reference change<\/td> Periodically, based on thresholds<\/td><\/tr> Detects<\/td> Simple “no references left” cases<\/td> Reference cycles<\/td><\/tr> Can be disabled<\/td> No fundamental to CPython<\/td> Yes via gc.disable()<\/td><\/tr> Overhead<\/td> Small, constant, per-operation<\/td> Occasional, batched pauses<\/td><\/tr> Handles<\/td> Every object<\/td> Only container objects<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Avoiding Reference Cycles in Practice<\/strong><\/h2>\n\n\n\n
\n
import weakref\n\nclass Node: pass\n\na = Node() ref = weakref.ref(a) print(ref()) # <Node object>\n\ndel a print(ref()) # None<\/code><\/pre>\n\n\n\n