If you want to be a top-tier JavaScript developer, then you need to have mastery over how JavaScript handles memory. So, in this video, I'm going to be covering everything from the simple concepts of how garbage collection works all the way up to the incredibly complex concepts of how to use your advanced debugging tools to find things like memory leaks inside of your application. Welcome back to Web Dev Simplified. My name is Kyle, and my job is to simplify the web for you so you can start building your dream project sooner. Now, the very first thing I want to mention anytime you're dealing with memory management is I highly recommend you do this inside of an incognito tab in your browser. For example, here I have this entire web app open in an incognito tab. It's a blank web app because there's not much going on, but I want you to open it in an incognito tab because otherwise, you're going to get memory for all your extensions and all the other things you have downloaded on your browser. So, doing

it in Incognito just makes it easier to figure out what's actually part of your application versus what's external to your application. Now, the first thing I want to talk about is how JavaScript handles garbage collection because understanding that allows us to solve a lot of memory problems automatically. And the nice thing about JavaScript compared to languages like C and C++ is garbage collection handles all the memory management for you. For example, it'll clean up memory when it's no longer needed. Now, in this very simple bit of code, we have just a class called test, and we have two objects that we're creating. We're creating a test object, and we're creating this string right here. And both of these variables are essentially Global variables. They're available everywhere in our code, which means that they're never going to get cleaned up by this garbage collection because they could be used other places in our code since these are essentially Global variables. But if we create a scope, we could do something like inside of an if block like this, or we can just

create a scope by using these curly braces. Just like this, this is going to create a scope where the variables are only accessible inside that scope. So, for example, if I instead create some variables in here, and instead of calling them Global, I'm just going to call them inner. There we go. So now we have this inner test and this inner string. You can already see they're gray out because they're never being used. So let's just go ahead and console log inner test.name, and we're going to console log the inner string as well, just they're actually being used. So JavaScript will create space for them, but these variables are inside of a scope right here, and they're never accessible outside that scope, which means as soon as this scope is done executing, these variables are automatically going to be cleaned up out of memory by JavaScript for us. And you'll notice on the right-hand side of my screen, I have all this information. This is the memory tab inside of the Chrome debugger tools, and this allows us to look at every single

thing that's stored in memory for our entire application. It's a ton of information, but it can be incredibly useful for understanding how garbage collection works, as well as finding problems inside of your actual code. Now, the easiest thing to get started with is to use this Heap snapshot. Essentially, that just takes a snapshot of everything that's stored inside of your HEAP memory all at once. It just takes a snapshot of it and shows it to you. So, if we click this record button right here, that'll actually take the snapshot for us. You'll notice we have 2.2 megabytes of information being stored, and as you can see, it's a lot of stuff that's showing up inside of this list of information that we have stored. We have strings, we have arrays, we have functions. I mean, you can see there's almost 10,000 strings being stored, a lot of these strings are essentially strings for different error messages and so on that they may need to show us. But if we want to search for a specific string we have, for example, if I

want to search for Global string. I can hit Ctrl + F. That gives me this finder down here. I can just type in global string, and this is going to show me every single place that I have Global string Bane defined. So, the first thing that pops up right here is essentially all of my code. This entire file is stored as a string inside of my memory. So, obviously, that code for Global string is going to be inside this file. And the next place is the actual string itself. As you can see, if I scroll up, this is inside of the strings category. There we go. You can see this is inside the string category, and it is storing that Global string directly inside of here. So, we can see that that variable is being stored, and you can see exactly how much space that's taking up inside of the memory of my program. So, we can really see exactly what's going on down to the individual bits and bytes of your code. Now, I know this is a lot of overwhelming information, but I promise you by the end of this video, this is

going to make a lot more sense to you now. The next thing I want to search for is this inner string. So we can come in here, let's search for inner string, do a little paste, and we'll notice it obviously shows up right here where we've created all of our code. That's this entire file. But if we hit enter again, you'll notice inner string is actually still stored inside of our memory right here in the strings category. Now that may be a little bit counterintuitive because I told you garbage collection will clean things up that are no longer needed. But in this case, you can see the string is still there even though it should be removed since we're outside of this scope. We can actually see this even more in action if we search specifically for the class CL of test. So if we search for that class of test and we open this up, you notice only one thing is being stored in here. That is my global test, my inner test for that inner test variable we have inside the scope that is not being stored.

anywhere in our memory, it has been cleaned up and removed. The reason that there's a difference between the way that it handles classes and the way that it handles strings is because JavaScript has two different types of values. There are primitive values; these are essentially strings, booleans, numbers, all those things that are built into JavaScript. And then there are objects, arrays, and other things that are built on top of primitives. So, anytime you have something like an object, an array, a class, anything like that, those are going to be garbage collected automatically. But anytime you use a string, a number, a boolean, those will stay in memory essentially forever because they are not being garbage collected. That's why the string for inner string still shows up when I actually search for that down here. You can see that this is showing up here while that inner test variable is removed because this is essentially an object, and objects are automatically garbage collected. To show you a little bit more exactly how this is working, I'm going to throw in a debugger statement right here. So, I'm going to put a

debugger statement inside of this particular scope, and I can actually show you the difference between what it looks like before and after we get to this point. So, I'll give this a quick save. You can see we're in that debugger statement. I'm going to clear out my current snapshot and create a brand new snapshot. And now what I'm going to do is I'm going to search for test. You notice inside of here we have three different test things. Inside here we have a test for Global, we have another test for Global, and then we have a test for inner test. Now, the reason we have two Global tests showing up right now is just because I'm using live server. So, every time I refresh my site, it keeps the data from before. So, there may be some things where this one hasn't been garbage collected quite yet, but hopefully will eventually be garbage collected. You'll also notice if I search for inner string that the inner string is still showing up inside of there, as well as my outer string, or I called it Global.

string you can see that that is still showing up inside of here as well. Now, if I were to let this code continue by just clicking the play button right here, that'll let my code continue on, and I go into my memory, and I create a brand new snapch. We should hopefully see inside of here that if I search for a test, we are now back to just one single global test. So, this is actually really a good example of how garbage collection works. You noticed back in this example when we searched for only our test class, we had three different test objects, and two of them were our global test. That's because originally I had one global test, and then I refreshed my application, so it refreshed my page, and I created a brand new global test. But the old one was still stored in memory because it hadn't gone around and cleaned up my memory yet, 'cause garbage collect just happens randomly over some period of time. So, I had two of these global test variables both being stored. Then eventually a

little while later when I took this second snapshot. Garbage collection had happened, and it cleaned up both my inner test, which is no longer needed, as well as that original global test that, again, is now no longer needed since that file essentially no longer exists since I refreshed my application. Now, the reason I'm getting this refresh behavior is because I'm using something called live server, which automatically refreshes my site every time I save my files, and it's doing some magic behind the scenes to make all of that work. But this essentially would work anytime, like you call a function. If you call a function multiple times back to back, it may have multiple instances of that variable still in memory just because it hasn't gone through and actually done garbage cleanup yet with the garbage collector. So, that's pretty much the basics of garbage collection. Anytime you have an object or any other non-primitive type, it's going to be removed from memory anytime it is no longer needed, and there's different algorithms that are used behind the scenes to try to figure

out when this thing is no longer needed, but essentially you can assume whenever the code is outside of its current scope, it's probably going to get garbage collected event now. This big memory thing, if you don't have something to search for, is incredibly difficult, and the annoying thing is you can't search for objects very easily inside of here. You can search for classes very easily, but objects are really hard to search for. So one thing that I like to do to make this a little bit more manageable on what's actually going on is I like to add a debugger statement at the very top of my file if I need to do some really complex memory management. So I'm going to add that debugger to the very top of my file. You can see I've hit it right here, go into my memory, clear everything out, and create a brand new snapshot. This essentially will a lot of the generic JavaScript stuff that gets automatically created when your program actually gets started. This will hopefully minimize the amount of new stuff that's being created.

then we can go ahead and just click continue so it runs our entire application. And now we can take another brand new snapshot. You notice both these snapshots have a ton of information inside of them, but the really nice thing is there's a drop-down up here that I can say I only want to look at the things that were allocated between snapshots 1 and 2. And now you can see the list of things that's much smaller, and these are only the things that were given memory between the time that this debugger statement ran at the very top of my application and then after all my code ran and I actually clicked the snapshot button. This is a much more manageable way to look at your code because obviously there's a lot of stuff in here automatically generated by JavaScript, but I can look at this and be like, Okay, here's my test right here. That's my test variable. If I look inside of string, you can see I have some string information being shown up inside of there. Now the reason that you don't

actually see global string or inner string inside of here is because those are created essentially immediately. That's just kind of how JavaScript works. But generally, if you're dealing with memory problems, it's not because of strings; it's probably because of objects and other things. So, this gives you a really clean way to essentially look at your code and figure out what's actually happening. And I love being able to go between different snapshots, and using debuggers is a great way to do this. For example, I threw a debugger originally into this section of my code because I wanted to see what essentially was being created in this very section of my code. What did the memory look like at that exact moment? So, debugs are a great way to actually make sure you take a snapshot exactly where you want to, and then you can use this only looking at things between multiple snapshots to see exactly what happened between each snapshot. Now, in order to talk other potential problems, I want to clear this out and talk about the different types of profiling types we have these other

two options are essentially the same thing. This first one is allocating essentially all of your different memory across the timeline. So when I click this record button, it'll actually record memory uses until I click stop. This one right here called allocation sampling is just a version that samples at a much lower frequency. So instead of being completely up to date with exactly what memory it is at all time, it just takes snapshots periodically and then compares those snapshots to each other. It's more so if you want to do something long-running as compared to this option which is much more accurate but it's much more performance-intensive. So it's not as good for maybe longer-running tasks. So I want to talk about how these can be really great specifically when you want to deal with a memory leak in your code. So if your application is just ballooning and ballooning in size, this will help you figure out what that problem is. So what I'm going to do is I'm going to remove all of this code so

we can talk about and show how this works. I'm going to come in here with a document. add event listener. I'm going to add a click event listener that takes in an object. I'm going to create a variable a, which is just going to be equal to a string. We just come in here. This is going to take our client X, and it's going to say position or something. It really doesn't matter what this thing does. I just want to show you how this allocation instrument timeline works. So, what happens when my application starts up? I can click this play button, and you can see I have a gray bar going along. Every time you see blue on that bar, that means there's new memory being allocated. So, every time I click on my document, I'll just bring this over real quick. Every time I click on S of here, you can see a blue bar showing up. Even when I was moving things around, there was a blue bar showing up because there's different size events and so on that are happening in JavaScript to allocate all.

this additional memory, but the main memory is from me clicking on this. You can see pretty much every time that I click, I get this blue bar showing up on the right-hand side. Now I'm going to bring this back over so it's out of the way. We can stop this test, and we can see all the information about all the memory that was allocated during the entire time that this snapshot was running, which is a really great way, again, to only look at memory that was created during a specific time period. Now I want to talk about how we can use this to actually find memory leaks inside of our code. So I'm going to replace this code real quick with some code that looks like this. Essentially, we're creating a map starting at index zero, and every single 1 millisecond, we're adding a brand new entry to that map and adding one to I every single time. Now if I give this a quick save, essentially what's happening behind the scenes now is every single millisecond, I'm adding a new value to a map. So we can come in here, we

can click play, and you can see right here immediately there's tons of information being stored into memory. Every single Blue Bar means there's more information being stored into memory, and it's obviously going to constantly grow and grow and grow and grow. I'll click stop on this for now, and we can actually search for our map. You can see there's eight Maps being stored. We just need to find the one that is ours. So, if we open up the table, we should be able to find one as soon as we get the table open that has all of our information inside of it. Looks like it was none of these. Must be this top one right here. There we go. You can see I open up my table, and this map right here has tons of information in it. If we can even look at the size of this table, you can see it is massive. It's 114,000 bytes of space that's being taken up. Compared to almost everything else, that is a much smaller amount of size being stored inside of here. If we look at the retained size right here

245,000. This is 10% of all the memory in our entire application. It's going to this one particular map. So, this is a great way for us to be able to detect that there's a memory leak inside of our application. Because you can see we're constantly allocating memory, and this thing right here is constantly growing. We can even do this with normal snapshots. I can come in here for a keep snapshot, take a quick snapshot, and you can see that if I look at my retained size, I search for map, and we look inside here, you can see 28% of my application is taken up by just this map at 924,000 bytes. Now, if we do another snapshot and again search for map, you can see that this is growing. It's gone from 924 to 997. We take another snapshot. We should see that this eventually will surpass a million. So, it's just constantly growing and growing. So, this is how we can narrow down and figure out what's actually causing memory leaks inside of our application.

we can see it is this map, and we can find the really large map. And if we look at the table for it, we can see, Hey, it's this map that has all these different index values inside of it. And hopefully, from there, you can narrow it down inside of your code. Now, this was actually a purposeful example of me using the map because I want to talk about how you can use a weak map instead to solve certain memory issues that you're having in your application related to possibly using Maps or sets. That's because both maps and sets have a weak map and a weak set version. Now, the only difference between the normal map and the weak map and the normal set and the weak map is that weak map will garbage collect your keys automatically for you. So, in our case, as you can see here, this keyi is no longer used ever again in our application after this point. We're incrementing it by one. It no longer exists. So, we realistically could remove this value from our map because we know we can never access it.

again now in some cases, you want to have a map where you can later access it by some other means, by automatically typing in a value from a user input or something like that. But sometimes you have a map where you only want to store the value and keep the value in that map if the key is essentially still around. That's the case of a weak map and a weak set. Now, a weak map and a weak set require you to use objects as the keys because those are the only things that are garbage collected. So let's convert this to an object that uses this I variable inside of here instead, and automatically, just by doing that, we should actually clean up our entire memory leak. Because what's happening is this object right here is being created and then it's automatically being garbage collected because it's no longer accessible outside of this particular scope. We can even make this a little bit more clear by saying that this is going to be our object, and we'll use this as the key right here, as you can see this

object is never accessible outside this scope, so essentially it's setting this variable in the map and then garbage collection is automatically cleaning it up for us. So, we'll give that a save, clear out all of our s snot, we'll go back to this allocation instrument, and if we give this a quick run, you can see with the snapshot recording, we get no giant blue bars showing up anywhere in our application. When we stop this and we look for our map, and we come into here, you can see right now we have that big map from before. That's, I think, because of our way that our live reloading is working, so I'm actually going to hard refresh my application to hopefully clear out everything that's inside of there. And now I'm going to do another brand new snapshot, and then we're going to stop that snapshot. And I had to go through and do a little bit more clearing, but I got all the extra data removed, so now we're just left with essentially our normal application. So, I'm going to give this a quick save. I'm

going to do a snapshot. Start. You can see there's a couple of places where memory is being allocated, but not too bad. And if we stop and we search for map, you can see that maps are taking up almost no space at all, 0%. And we specifically have all of our weak Maps. This weak map right here is the one that we created. And if we look inside the table, you can see there's absolutely nothing being stored inside of our table. I can even prove this by adding a specific value inside of here. We're going to set this to object, which say outer object is going to have an outer value. And then let's create that outer object. This is just something that won't be garbage collected, so we'll say outer object is equal to this. We'll say I is ne1. There we go. Now we give that a quick save, do my Snapshot again, give it a second to run, open this up, search for weak map specifically. We can pull up our weak map, and you can see the only thing being

stored in here is our outer object, and then we just have a bunch of other stuff that's in the process of being deleted because, as you can see, it's essentially labeled as a whole, which means there's no data being stored there because it's been garbage collected. So, the idea behind a weak map and a weak set is essentially anytime that the object that you use as the key leaves the scope of that particular map or set, it's going to delete all the information related to that from the map. So, it's going to delete the key, and it's going to delete the value, while a normal map and a normal set keep all the information in them as long as possible. Another difference between the two is you cannot loop through a weak map or a weak set because there's really nothing to loop over because it only keeps in place the keys that actually exist. So, there's constantly data being removed from it, which is why you can't loop over it. Now, this is a pretty niche use case. You're

probably not going to use weak Maps or weak sets all that often because most of the time when you have a map or set, it's because you want to keep data in their long term and reference it later by creating brand new objects or brand new values that reference those things. While in the case of a weak map and a weak set, it's where you have to deal with data that's constantly going to be changing. Maybe you have a really large map, and you want to make sure you automatically remove values from it that are no longer needed. Those are the particular scenarios where a weak map would be really useful. Now, I know this is a ton of information that I covered, but if you want to go even deeper into debugging best practices and advanced debugging techniques, I highly recommend you check the video right here. That's an entire crash course on debugging. Also, if you enjoyed this video where I really deep dove into how JavaScript works, I highly recommend checking out my JavaScript simplified course. It teaches you everything.

You need to know about JavaScript to go from a beginner to an absolute master of web development, no matter what your skill level is. So, if you're interested in that, I'll leave a link in the description for you. With that said, thank you very much for watching, and have a good day.

Only The Best Developers Understand How This Works

Web Dev Simplified is all about teaching web development skills and techniques in an efficient and practical manner. If you are just getting started in web development Web Dev Simplified has all the tools you need to learn the newest and most popular technologies to convert you from a no stack to full stack developer. Web Dev Simplified also deep dives into advanced topics using the latest best practices for you seasoned web developers.

I started Web Dev Simplified in order to share my passion for web development, and do what I truly love. Teach and inspire new web developers. I have been in love with full stack web development since 2015 when I did my first internship as a web developer. Ever since then I have pursued my passion, learning everything there is to know about web development. Over the years I have taught many colleagues and friends the joys of web development, and cannot wait to teach you.

Thank you for watching!

Only The Best Developers Understand How This Works

Only The Best Developers Understand How This Works

스크립트