Does Javascript have memory leaks ? If so, how to avoid it? In view of the fact that several people have asked me similar questions recently, it seems that no one has systematically studied this part of the content. Therefore, I plan to share with you some information that I compiled a few years ago.
First of all, it can be said with certainty that some ways of writing JavaScript will cause memory leaks, at least under IE6. Therefore, today when IE6 refuses to retire, we still need to understand the relevant knowledge (although in most cases, the memory leak caused by js is not the main reason for slowing down the computer). Relevant research is mainly concentrated in the years 2005-07. This article does not have any new ideas. If you have friends who have studied it back then, you can just ignore it.
As a front-end developer, when understanding these problems, you need to know what they are and why. Therefore, before introducing js memory leaks, let's start with why there are memory leaks.
When talking about memory leaks, we have to talk about the way memory is allocated. There are three ways to allocate memory, namely:
1. Static Allocation: The allocation form of static variables and global variables. If we think of a room as a program, we can think of statically allocated memory as durable furniture in the room. Usually, they don't need to be released and recycled because no one throws armoires out the window as trash every day.
2. Automatic Allocation: A method of allocating memory for local variables on the stack. The memory in the stack can be automatically released with the pop operation when the code block exits.
This is similar to people who come to a room to do things. Once the things are done, they will leave on their own, and the space they occupy will be automatically released as these people leave.
3. Dynamic Allocation: A method of dynamically allocating memory space in the heap to store data. That is, the memory applied for using malloc or new when the program is running, we need to release it ourselves using free or delete. The lifetime of dynamic memory is determined by the programmer. Once you forget to release it, it will inevitably cause a memory leak. In this case, the memory blocks in the heap are like the napkins we use every day. After using them, we have to throw them into the trash can, otherwise the house will be a mess. Therefore, lazy people dream of having a household robot to clean with them. In software development, if you are too lazy to free memory, then you also need a similar robot - which is actually a garbage collector implemented by a specific algorithm. It is precisely some defects in the garbage collection mechanism itself that lead to JavaScript memory leaks.
A few years ago, I read an article called "An Interesting History of Garbage Recycling", which gave an in-depth explanation of the garbage collection mechanism.
Just like supercharging, a technology used by many luxury cars as a selling point, which was actually used by Mercedes-Benz in the 1910s, garbage recycling technology has been around for a long time. The Lisp language, born at MIT around 1960, was the first language that relied heavily on dynamic memory allocation technology. Almost all data in Lisp appears in the form of "tables", and the space occupied by "tables" is in the heap. dynamically allocated. The innate dynamic memory management feature of the Lisp language requires the designers of the Lisp language to solve the problem of automatic release of each memory block in the heap (otherwise, Lisp programmers will inevitably be overwhelmed by countless free or delete statements in the program). This directly led to the birth and development of garbage collection technology.
The three most basic garbage collection algorithms also appeared together at that time. Let’s take a look at them one by one:
Reference Counting algorithm: This may be the first method that comes to mind. To put it figuratively, reference counting can be understood in this way. There are a lot of white papers in the house, and these papers are like memories. Using memory is like writing on these pieces of paper. The memory can be used at will, but there is a condition. Anyone who uses a piece of paper must write a count of 1 on the corner of the paper. If two people use a piece of paper at the same time, the count becomes 2, and so on. When a person finishes using a piece of paper, the count on the corner must be decremented by 1. In this way, once the count becomes 0, the garbage collection conditions are met, and the robot waiting aside will immediately throw the paper into the garbage. box. The reference counter-based garbage collector runs faster, does not interrupt program execution for a long time, and is suitable for programs that must run in real time. However, the reference counter increases the overhead of program execution; at the same time, there is another biggest problem. This algorithm has a flaw, that is, once a circular reference is generated, the memory will be leaked. For example, we new two objects a and b. At this time, the counts of a and b are both 1. Then, we point an attribute of a to b, and an attribute of b to a. At this time, due to the reference Relationship, the counts of a and b both become 2. When the program ends and exits the scope, the program automatically decrements the count of a by 1. Since the count of a in the end is still 1, a will not be released. Similarly , the final count of b is also 1, b will not be released, and the memory is just leaked!