Menu
I would like to understand what kind of code causes memory leaks in JavaScript and created the script below. However, when I run the script in Safari 6.0.4 on OS X the memory consumption shown in the Activity Monitor does not really increase.
Is something wrong with my script or is this no longer an issue with modern browsers?
<html> <body> </body> <script> var i, el; function attachAlert(element) { element.onclick = function() { alert(element.innerHTML); }; } for (i = 0; i < 1000000; i++) { el = document.createElement('div'); el.innerHTML = i; attachAlert(el); } </script> </html> The script is based on the Closure section of Google's JavaScript style guide: http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml?showone=Closures#Closures
EDIT: The bug that caused the above code to leak has apparently been fixed: http://jibbering.com/faq/notes/closures/#clMem
But my question remains: Would someone be able to provide a realistic example of JavaScript code that leaks memory in modern browsers?
There are many articles on the Internet that suggest memory leaks can be an issue for complex single page applications but I have a hard time finding an examples that I can run in my browser.
747
Memory leaks can and do happen in garbage collected languages such as JavaScript. These can go unnoticed for some time, and eventually they will wreak havoc. For this reason, memory profiling tools are essential for finding memory leaks.
Just forgetting to set a reference to null or more often forgetting to remove one object from a collection is enough to make a memory leak. Of course all sort of listeners (like UI listeners), caches, or any long-lived shared state tend to produce memory leak if not properly handled.
In simple terms, a Node. js memory leak is an orphan block of memory on the Heap that is no longer used by your app because it has not been released by the garbage collector. It's a useless block of memory. These blocks can grow over time and lead to your app crashing because it runs out of memory.
In contrast, JavaScript automatically allocates memory when objects are created and frees it when they are not used anymore (garbage collection).
You're not keeping the element you've created around and referenced anywhere - that's why you're not seeing the memory usage increase. Try attaching the element to the DOM, or store it in an object, or set the onclick to be a different element that sticks around. Then you'll see the memory usage skyrocket. The garbage collector will come through and clean up anything that can no longer be referenced.
Basically a walkthrough of your code:
Everything is centric around the element existing. Once there isn't a way to access the element, the onclick can't be accessed anymore. So, since the onclick can't be accessed, the function that was created is destroyed.. and the function had the only reference to the element.. so the element is cleaned up as well.
Someone might have a more technical example, but that's the basis of my understanding of the javascript garbage collector.
Edit: Here's one of many possibilities for a leaking version of your script:
<html> <body> </body> <script> var i, el; var createdElements = {}; var events = []; function attachAlert(element) { element.onclick = function() { alert(element.innerHTML); }; } function reallyBadAttachAlert(element) { return function() { alert(element.innerHTML); }; } for (i = 0; i < 1000000; i++) { el = document.createElement('div'); el.innerHTML = i; /** posibility one: you're storing the element somewhere **/ attachAlert(el); createdElements['div' + i] = el; /** posibility two: you're storing the callbacks somewhere **/ event = reallyBadAttachAlert(el); events.push(event); el.onclick = event; } </script> </html> So, for #1, you're simply storing a reference to that element somewhere. Doesn't matter that you'll never use it - because that reference is made in the object, the element and its callbacks will never go away (or at least until you delete the element from the object). For possibility #2, you could be storing the events somewhere. Because the event can be accessed (i.e. by doing events[10]();) even though the element is nowhere to be found, it's still referenced by the event.. so the element will stay in memory as well as the event, until it's removed from the array.
92
update: Here is a very simple example based on the caching scenario in the Google I/O presentation:
/* This is an example of a memory leak. A new property is added to the cache object 10 times/second. The value of performance.memory.usedJSHeapSize steadily increases. Since the value of cache[key] is easy to recalculate, we might want to free that memory if it becomes low. However, there is no way to do that... Another method to manually clear the cache could be added, but manually adding memory checks adds a lot of extra code and overhead. It would be nice if we could clear the cache automatically only when memory became low. Thus the solution presented at Google I/O! */ (function(w){ var cache = {} function getCachedThing(key) { if(!(key in cache)) { cache[key] = key; } return cache[key]; } var i = 0; setInterval(function() { getCachedThing(i++); }, 100); w.getCachedThing = getCachedThing })(window); Because usedJSHeapSize does not update when the page is opened from the local file system, you might not see the increasing memory usage. In that case, I have hosted this code for you here: https://memory-leak.surge.sh/example-for-waterfr
This Google I/O'19 presentation gives examples of real-world memory leaks as well as strategies for avoiding them:
getImageCached() returns a reference to an object, also caching a local reference. Even if this reference goes out of the method consumer's scope, the referenced memory cannot be garbage collected because there is a still a strong reference inside the implementation of getImageCached(). Ideally, the cached reference would be eligible for garbage collection if memory got too low. (Not exactly a memory leak, but a situation where there is memory that could be freed at the cost of running the expensive operations again).getImageCached().FinalizationGroup API.Please see the linked video for JS code with line-by-line explanations.
More generally, "real" JS memory leaks are caused by unwanted references (to objects that will never be used again). They are usually bugs in the JS code. This article explains four common ways memory leaks are introduced in JS:
An interesting kind of JavaScript memory leak documents how closures caused a memory leak in the popular MeteorJS framework.
37
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
