You should know this
Memory leaks are a problem every developer has to face eventually.
What are memory leaks?
In essence, memory leaks can be defined as memory that is not required by an application anymore that for some reason is not returned to the operating system or the pool of free memory.
Of course, you can favor different ways of managing memory, and these ways may reduce the chance of leaking memory.
However, whether a certain piece of memory is unused or not is actually an undecidable problem.
Memory Life Cycle In the high-level language, We will just read and write to the memory explicitly (Use Memory). In the low-level language, all three steps the developer needs to take care of explicitly.
✅ Allocate memory to the variables.
✅ Use the defined variables.
✅ Remove them from the memory.
The reason why we need to understand the concept of memory management while learning any programming language is to prevent memory leaks.
In any program, memory leaks may lead to several problems, including slow execution, program crashing, high latency (large delays in processing the data), etc.
💡 The most important task in managing memory is to detect the unused variables in a program and remove them from memory.
When the memory is no longer needed anymore, then the allocated memory will be released. Memory leak and most of the memory-related issues come while releasing the memory. The hardest part is finding the memory which is no longer needed and it is tracked down by the garbage collector.
Garbage Collector 👇
In simple terms, the algorithm “mark-and-sweep” consists of the following steps:
1️⃣ The garbage collector builds a list of “roots”.
Roots usually are global variables to which a reference is kept in code. The window object is always present, so the garbage collector can consider it and all of its children to be always present (i.e. not garbage).
2️⃣ All roots are inspected and marked as active.
All children are inspected recursively as well. Everything that can be reached from a root is not considered garbage.
3️⃣ All pieces of memory not marked as active can now be considered garbage.
The collector can now free that memory and return it to the OS.
Modern garbage collectors improve on this algorithm in different ways, but the essence is the same: reachable pieces of memory are marked as such and the rest is considered garbage.
👉 Accidental global variables
In the case of browsers, the global object is a “window”. For instance:
but, is in fact
bar was supposed to hold a reference to a variable only inside the scope of the
someFn function and you forget to use var to declare it, an unexpected global variable is created.
To prevent these mistakes from happening, add
👉 Forgotten callbacks or timers
The example below illustrates what can happen with dangling timers: timers that make reference to nodes or data that is no longer required.
The object represented by
node maybe removed in the future, making the whole block inside the interval handler unnecessary. However, the handler, as the interval is still active, cannot be collected (the interval needs to be stopped for that to happen).
If the interval handler cannot be collected, its dependencies cannot be collected either. That means that,
someResource which presumably stores sizable data, cannot be collected either.
For the case of observers, it is important to make explicit calls to remove them once they are not needed anymore
Frameworks and libraries such as jQuery e.t.c do remove listeners before disposing of a node.
This is handled internally by the libraries and makes sure that no leaks are produced, even when running under problematic browsers such as 🎃 the old Internet Explorer.
👉 Out of DOM references
Sometimes it may be useful to store DOM nodes inside data structures.
Suppose you want to rapidly update the contents of several rows in a table. It may make sense to store a reference to each DOM row in a dictionary or array.
When this happens, two references to the same DOM element are kept: one in the DOM tree and the other in the dictionary.
If at some point in the future you decide to remove these rows, you need to make both references unreachable.
If you enjoyed this article, please share it with your developer friends and in social media.