This article assumes you’re already comfortable writing simple Python programs and know the basic syntax (
if,for, functions, lists). Here we focus not on how to use Python, but on why it works the way it does.
In the previous article, we learned about reference counting.
The idea turned out to be surprisingly simple.
As long as there is at least one reference to an object, the object stays alive.
When the last reference disappears, Python knows the object is no longer needed and frees its memory.
At first glance, this mechanism seems perfectly sufficient.
But let’s look at a small example.
a = []
b = []
a.append(b)
b.append(a)At first glance, nothing unusual is happening.
We created two lists.
But now each list contains a reference to the other.
Conceptually, it looks like this:
┌─────┐ ┌─────┐
│ a │ ─────► │ [] │
└─────┘ └──┬──┘
│
▼
┌────────┐
│ [] │
└────┬───┘
▲
│
└──────────────We’ve created a small cycle.
Now let’s delete both names.
del a
del bWhat happens?
At first glance, it seems like both lists should disappear.
After all, the names a and b no longer exist.
However, the situation is a bit more complicated.
Yes, the program has indeed lost the ability to reach these objects.
But the objects themselves still hold references to each other.
The first list knows about the second.
The second knows about the first.
As a result, their reference counts never reach zero.
Each object continues to reference its neighbor.
This creates a rather strange situation.
The program can no longer access these objects.
There is no way to retrieve them.
But reference counting cannot free their memory either.
If Python relied solely on reference counting, this memory would remain allocated until the program terminated.
Fortunately, that isn’t what happens.
This is where another mechanism comes into play.
It’s called the Garbage Collector.
Its job is to find objects that are no longer reachable, even if their reference counts are not zero.
You can think of Python as occasionally asking itself:
“Are there any objects that can no longer be reached from the running program?”
If it finds such objects, it removes them along with all of the references between them.
This is why reference cycles do not cause permanent memory leaks.
One important thing to understand is this.
The Garbage Collector does not replace reference counting.
It simply helps reference counting deal with situations that reference counting alone cannot solve.
You can think of these two mechanisms as working together.
First, reference counting quickly frees the vast majority of objects.
Then, from time to time, the Garbage Collector checks whether there are any “forgotten islands of memory” that the program can no longer reach.
In practice, most objects are reclaimed through reference counting.
The Garbage Collector steps in much less frequently.
As a result, in an ordinary program, you may never even notice that it exists.
But without it, any program that created reference cycles would gradually consume more and more memory.
Looking back at everything we’ve covered so far, it becomes clear that there is no magic involved.
First, we learned that variables are just names.
Then we saw that multiple names can refer to the same object.
We explored when an object is modified and when a new object is created.
We learned that del removes a name, not an object.
We discovered that Python keeps track of the number of references to each object.
And finally, we saw why reference counting alone is not enough.
Together, these ideas form a coherent picture of how Python manages memory.
This naturally leads to another interesting question.
We’ve said several times that a name refers to an object.
But where does Python actually store all these names?
Why is the same variable sometimes accessible inside a function and sometimes not?
And how does Python know which variable to use when the same name appears in different parts of a program?
We’ll answer these questions in the next article.