This course has been updated! We now recommend you take the Introduction to Dev Tools, v3 course.
Transcript from the "Causes of Memory Leaks" Lesson
[00:00:03]
>> Jon Kuperman: Memory leaks. And so memory is kind of a tricky thing. In some programming languages, you have to be very explicit about memory. I'm not sure if any of you have ever used a language before where you have to actually declare, I'm making an array, and it's gonna be four by seven.
[00:00:20] I'm gonna put this in it, and maybe you're gonna have to clean up the memory when you're done with allocating and deallocating things. But scripting languages aren't like that, right? You're just like, I need an array. I don't know how big it's gonna be yet, and you're just kinda write the code that you want, and it works.
[00:00:34] It's really nice. And so the basic way that memory is kinda working is you allocate it, so you declare variables, and you put stuff in them, and anything like that. You use it and then you release it, right? And that's kind of the way that things should work.
[00:00:48] So what we call a memory leak in JavaScript is when something can't be released, when that third thing can't happen. And so what you'll see is that, what you really should see is that, and we'll get into the graphs, is that you use whatever memory you need to use, cuz that's what you're doing.
[00:01:03] And then, when you're done with it, you should see it all go back down to zero. It should be clear, right? You make all the arrays, you do all the stuff, then you pop up the domain, and you should delete all those things, and you're back to zero.
[00:01:11] So the healthy memory graph will kind of look like this, rising and falling wave, or even sometimes it'll go up and it'll hit, cuz you need to keep all that stuff in memory, if you're doing graphs and stuff like that. And then it'll just stay really flat, so it's like you use whatever you use, and then it stays.
[00:01:26] What we don't wanna see is what we call the jigsaw. Sorry, I'll do it, trying to do it at your angle. But you don't wanna see it just growing and growing and growing and never going back down. That's what we're always looking for is just memory that just keeps growing, especially when you're not doing anything on the application.
[00:01:41] So there's a few things that cause memory leaks that are really high level. Unfortunately, they are harder to spot in big code bases cuz it's just not as obvious. But a few things, so one example would be an accidental global. So if you've taken any of Kyle Simpson's courses on JavaScript, if you do something like this, you have a function you forget to put a var or a const declaration.
[00:02:04] And you're not in the strict mode, it will start looking up the scope chain to see if that function has been declared like, what are you trying to say here? And if it gets all the way to the global to the window object that doesn't have one, it tries to be helpful, and it just creates one for you.
[00:02:17] So then even after this function has done called, and you think it would be able to garbage collect or to clean up the variable inside of it, it's not able to. Because now, that variable lives on the global window object. So if instead of a string that had a huge array of 10 million items in it, that's there forever now.
[00:02:33] That's probably not what you want. Another one are any kind of forgotten intervals and timers. So the setInterval and the setTimeout APIs, they both return a token that you can call cancel on, right? So instead of doing this, setInterval, you probably wanna do something like const, my interval equals setInterval.
[00:02:50] And whenever you hit your finish condition, you end it, right? You remove that setInterval, cuz this is just gonna keep going forever, basically. The DOM and not the DOM. See this went a lot, it looks different in different frameworks. So basically, here, we make a variable called button, and we hit the DOM, we grab this button ID, and we stick it in there.
[00:03:10] And then later, we go ahead and we remove that child. So if you think about a graph of data or something like that, where as you're scrolling, you're adding and removing nodes, right? You hit the infinite scroll, and you add ten more rows of data, and you add ten more rows of data.
[00:03:23] Ideally, you should also be deleting form the top, so you don't have this monstrous app. But if you do something like this, we are removing the button from the DOM, right? Where it would [INAUDIBLE] out the DOM. But we haven't removed our handler to that global button variable, right?
[00:03:37] So that button variable still has this accessed instance that we grabbed there. Does that make sense? So we kinda clone something, and then you delete the thing that we cloned from, but you don't delete the clone. Those can build up over time. A lot of these you see when you're building more lower leveled tools, like if your building a virtual scroller, building a framework, things like that.
[00:03:56] These kind of memory leaks can be really devastating then. Whereas if you leave a DOM reference in your code, you're not going to notice that probably in your application code.