I've been reading a few different guides and tutorials, as I am interested in learning some best practices of programming. I was reading the How to be a Programmer guide, and there is a section about memory management, from which I have taken this piece of text:
But even with garbage collection, you can fill up all memory with garbage. A classic mistake is to use a hash table as a cache and forget to remove the references in the hash table. Since the reference remains, the referent is non-collectable but useless. This is called a memory leak. You should look for and fix memory leaks early. If you have long running systems memory may never be exhausted in testing but will be exhausted by the user.
The creation of new objects is moderately expensive on any system. Memory allocated directly in the local variables of a subroutine, however, is usually cheap because the policy for freeing it can be very simple. You should avoid unnecessary object creation.
I know Python has automatic garbage collection, although I don't understand much of how it works. But I know that objects will remain in memory if there are still references to it.
My question is: when should I worry about freeing objects from memory in Python? Preferably with some practical code as an example. They give an example of a hash table above, but I'm not sure if I understand it correctly, and so I can't put into practice. My idea is to follow the recommendation above and avoid such situations early in the development process!
Best Answer
Garbage collection works by releasing memory for objects that are no longer referenced by your software. Putting objects in a cache by reference, and then failing to eventually release those references, causes a memory leak because the garbage collector cannot release the memory used by objects that are still being referenced somewhere.
You should worry about this if, and when, you start holding references to objects for too long. A cache is the most obvious way to do this.
Like some other languages, Python has the concept of a Weak Reference. Use a weak reference when you don't want that reference to prevent the object from being garbage collected.