js memory leak scenarios, how to monitor and analyze them in detail

Preface

Q: What is a memory leak?

Literally, the memory requested was not recovered in time and was leaked.

Q: Why does a memory leak occur?

Although there is a garbage collection mechanism on the front end, when a piece of useless memory cannot be considered as garbage by the garbage collection mechanism, a memory leak occurs.

The garbage collection mechanism usually uses a flag clearing strategy. Simply put, it determines whether it is garbage by referring to whether it is reachable from the root node.

The above is the root cause of memory leaks. The direct cause is that when two things with different life cycles communicate with each other, one of them expires and should be recycled, but is still held by the other party, a memory leak occurs.

So, let's talk about which scenarios will cause memory leaks

What situations can cause memory leaks?

1. Accidental global variables

The life cycle of global variables is the longest. They survive until the page is closed, so the memory on global variables will never be recycled.

Memory leaks occur when global variables are used improperly, are not recycled in time (manually assigned null), or are mounted to global variables due to spelling errors.

2. Forgotten timer

The life cycle of setTimeout and setInterval is maintained by a dedicated thread of the browser, so when a timer is used on a page, if the timer is not manually released and cleaned up when the page is destroyed, the timer will still be alive.

In other words, the life cycle of the timer is not attached to the page, so when a callback function is registered through the timer in the js of the current page, and the callback function holds a variable or some DOM elements of the current page, it will cause the page to be destroyed. The part of the page that the timer holds references cannot be recycled normally, resulting in memory leaks.

If you open the same page again at this time, there are actually two copies of the page data in the memory. If you close and open it many times, the memory leak will become more and more serious. This scenario is easy to occur because people who use timers can easily forget to clear

3. Improper use of closures

The function itself holds a reference to the lexical environment in which it is defined, but usually, after the function is used, the memory requested by the function will be reclaimed.

However, when a function is returned from within a function, the returned function holds the lexical environment of the external function, and the returned function is held by other lifecycle objects, resulting in the external function being executed but the memory cannot be reclaimed.

Therefore, the life cycle of the returned function should not be too long, so that the closure can be recycled in time.

Normally, closures are not memory leaks, because holding the external function lexical environment is a feature of closures, which is to prevent this memory from being recycled.

It may be needed in the future, but it will undoubtedly cause memory consumption, so it is not advisable to overuse it.

4. Missing DOM Elements

The life cycle of a DOM element normally depends on whether it is mounted on the DOM tree. When it is removed from the DOM tree, it can be destroyed and recycled.

But if a DOM element is also referenced in js, then its lifecycle is determined by both js and whether it is on the DOM tree. Remember that when removing it, both places need to be cleaned up to recycle it normally.

5. Network callback

In some scenarios, a network request is initiated on a page, and a callback is registered, and the callback function holds some content of the page. Then, when the page is destroyed, the network callback should be unregistered. Otherwise, because the network holds part of the page content, part of the page content cannot be recycled.

How to monitor memory leaks

Memory leaks can be divided into two categories. One is more serious, and the leaked memory cannot be recovered. The other is less serious, which is caused by memory leaks that are not cleaned up in time. It can still be cleaned up after a period of time.

Regardless of which one, using the memory graph captured by the developer tool, you should see that the memory usage continues to decrease linearly over a period of time. This is because GC, or garbage collection, is constantly occurring.

For the first type, which is more serious, you will find that even after GC occurs continuously in the memory graph, the total amount of memory used is still increasing.

In addition, insufficient memory will cause continuous GC, and GC will block the main thread, which will affect the page performance and cause jams, so memory leaks still need to be paid attention to.

Let's assume such a scenario and use developer tools to check for memory leaks:

Scenario 1: A block of memory is requested in a function, and then the function is called repeatedly in a short period of time

// Click the button to execute the function once and apply for a piece of memory startBtn.addEventListener("click", function() {
	var a = new Array(100000).fill(1);
	var b = new Array(20000).fill(1);
});

The memory that a page can use is limited. When the memory is insufficient, the garbage collection mechanism will be triggered to recycle the unused memory.

The variables used within the function are all local variables. After the function is executed, this memory is useless and can be recycled.

So when we call this function repeatedly in a short period of time, we can find that when the function is executed, it is found that there is insufficient memory, and the garbage collection mechanism works to recycle the memory requested by the previous function. Because the previous function has been executed, the memory is useless and can be recycled.

So the graph showing memory usage is a horizontal line with multiple vertical lines in the middle, which actually means that the memory is cleared, re-allocated, cleared and re-allocated. The position of each vertical line is the time when the garbage collection mechanism works and the function is executed and re-allocated.

Scenario 2: A block of memory is requested in a function, and then the function is called repeatedly in a short period of time, but part of the memory requested each time is held externally

// Click the button to execute the function once and apply for a piece of memory var arr = [];
startBtn.addEventListener("click", function() {
	var a = new Array(100000).fill(1);
	var b = new Array(20000).fill(1);
    arr.push(b);
});

What’s the difference from the first picture?

It is no longer a horizontal line, and the bottoms of each vertical line in the horizontal line are not at the same level.

This is actually a memory leak.

We apply for two array memory in the function, but one of the arrays is held externally. Then, even after each function is executed, this part of the array memory held externally cannot be recovered, so only part of the memory can be recovered each time.

In this way, when the number of function calls increases, more memory cannot be recovered, and more memory leaks occur, causing the memory usage to continue to grow. In addition, you can also use the performance monitor tool. Find the More button in the developer tools and open this function panel. This is a tool that can monitor the usage of CPU, memory, etc. in real time. It is more intuitive than the above tool that can only capture a period of time:

The ladder-like rise indicates a memory leak. Every time a function is called, some data is held externally and cannot be recycled. The smooth rise indicates that the data can be recycled normally after each use.

Note that there is a straight line down the end of the first red box. This is because I modified the code, removed the line of code that applied for the array in the external holding function, and then refreshed the page and manually clicked GC to trigger the effect. Otherwise, no matter how you click GC, some memory cannot be recovered, and this effect cannot be achieved.

The above are some tools for monitoring whether memory leaks occur, but the next step is the key. Now that a memory leak is found, how to locate it? How do you know which part of the data was not recovered and caused the leak?

How to analyze memory leaks and find problematic code

To analyze the cause of memory leaks, you still need to use the Memory function of the developer tool. This function can capture memory snapshots, memory allocation within a period of time, and each function that triggers memory allocation within a period of time.

Using these tools, we can analyze which function operation caused the memory allocation at a certain moment, and analyze what are the objects that are repeated and not recycled.

In this way, the suspected functions and objects are known, and then the code is analyzed to see whether the object in this function is the culprit of the memory leak.

Let's take a simple example first, and then an example of a real memory leak:

Scenario 1: A block of memory is requested in a function, and then the function is called repeatedly in a short period of time, but part of the memory requested each time is held externally

// Every time you click a button, some memory cannot be recovered because it is held by external arr var arr = [];
startBtn.addEventListener("click", function() {
	var a = new Array(100000).fill(1);
	var b = new Array(20000).fill(1);
    arr.push(b);
});

Memory snapshot

You can capture two snapshots, perform a memory leak operation between the two snapshots, and finally compare the differences between the two snapshots to see which objects were added and which objects were recycled, as shown in the figure above.

You can also view a snapshot at a certain time and see what objects occupy a large amount of memory from the memory usage ratio, as shown in the following figure:

You can also use the garbage collection mechanism to see which objects occupy a large amount of memory among the objects reachable from the GC root node:

Starting from the above methods, you can check what objects are currently occupying a lot of memory. Generally speaking, this is the suspect.

Of course, this is not necessarily the case. When there are suspicious objects, you can use multiple memory snapshots to compare, manually force GC in the middle, and see if the reclaimed objects have been reclaimed. This is one idea.

Capture memory allocation within a period of time

This method can selectively view which function initiated each memory allocation moment and what object is stored in the memory.

Of course, memory allocation is a normal behavior. What you see here also needs other data to determine whether an object is a suspect, such as the memory usage ratio, or combined with memory snapshots, etc.

Capture the memory usage of a function over a period of time

This shows very little content, which is relatively simple and has a clear purpose, that is, which operations are applying for memory and how much memory is used within a period of time.

In short, these tools cannot give you a direct answer and tell you that xxx is the culprit of the memory leak. If it can be determined at the browser level, why doesn't it recycle it and cause a memory leak?

Therefore, these tools can only give you various memory usage information. You need to use this information and analyze which suspect objects are the culprits of memory leaks according to the logic of your own code.

Example Analysis

Here is an example of a memory leak that has appeared in many articles on the Internet:

var t = null;
var replaceThing = function() {
  var o = t
  var unused = function() {
    if (o) {
      console.log("hi")
    }        
  }
 
  t = {
        longStr: new Array(100000).fill('*'),
        someMethod: function() {
                       console.log(1)
                    }
      }
}
setInterval(replaceThing, 1000)

Maybe you haven't figured out whether this code will cause a memory leak. Don't worry.

Let's first talk about the purpose of this code. It declares a global variable t and a replaceThing function. The purpose of the function is to assign a new object to the global variable. Then there is an internal variable to store the value of the global variable t before it is replaced. Finally, the timer periodically executes the replaceThing function.

• Find the problem

Let's use the tool to see if there is a memory leak:

All three memory monitoring charts show that a memory leak has occurred: the memory increases in a ladder-like manner when the same function is executed repeatedly, and the memory does not decrease when GC is manually clicked, indicating that some memory leaks each time the function is executed.

This situation where even manually forced garbage collection cannot reduce the memory is very serious. If it continues for a long time, it will exhaust the available memory, causing the page to freeze or even crash.

• Analyze the problem

Now that we have determined that there is a memory leak, the next step is to find out the cause of the memory leak.

First, through the sampling profile, we locate the suspect on the replaceThing function.

Next, we take two memory snapshots and compare them to see if we can get any information:

Comparing the two snapshots, we can find that the array object has been increasing during this process, and this array object comes from the longStr attribute of the object created inside the replaceThing function.

In fact, this picture contains a lot of information, especially the nested picture below. The nested relationship is reversed. If you look at it backwards, you can find how the global object Window accesses the array object step by step. The garbage collection mechanism cannot recycle because there is such a reachable access path.

In fact, we can analyze it here. In order to use more tools, let's change the picture to analyze it.

Let's start directly from the second memory snapshot and see:

From the first snapshot to the second snapshot, replaceThing was executed 7 times, creating exactly 7 objects. It seems that these objects have not been recycled.

So why isn't it recycled?

The replaceThing function only saves the previous object internally, but when the function is finished, shouldn’t the local variables be recycled?

Continuing to look at the picture, you can see that there is a closure below that takes up a lot of memory:

Why can't the objects created inside be recycled every time the replaceThing function is called?

Because replaceThing is created for the first time, this object is held by the global variable t, so it cannot be recycled

In each subsequent call, this object is held by the o local variable inside the previous replaceThing function and cannot be recovered.

The local variable o in this function is held by the someMethod method of the object created when replaceThing is called for the first time. The object mounted by this method is held by the global variable t, so it cannot be recovered.

In this way, each time a function is called, the local variables created internally when the function was last called will be held, resulting in these local variables being unable to be recovered even after the function is executed.

It's a bit confusing to say it verbally, but here's a picture (deleted if it infringes your rights). When combined with the mark-and-sweep method (commonly known as the reachability method) of the garbage collection mechanism, it becomes very clear:

• Conclusion

By using the memory analysis tool, the following information can be obtained:

1. The memory usage of the same function call increases in a ladder-like manner, and the manual GC memory cannot be reduced, indicating a memory leak.
2. By capturing the memory usage over a period of time, we can determine that the suspected function is replaceThing
3. Comparing the memory snapshots, we found that the objects not recycled were those created inside replaceThing (including the longStr property of the storage array and the method someMethod).
4. Further analysis of the memory snapshot revealed that the reason for not recycling is that the object created by each function call is stored in the local variable o created internally during the previous function call.
5. The local variable o is not recycled at the end of the function execution because it is held by the someMethod method of the created object.

The above is the conclusion, but we still have to analyze why this happens, right?

In fact, this involves the knowledge point of closure:

MDN explains closure as the combination of a function block and the lexical environment in which the function is defined.

When a function is defined, there is an internal attribute of the scope that stores the current lexical environment. Therefore, once a function is held by something with a longer life cycle than the lexical environment it is in, the lexical environment held by the function cannot be recycled.

Simply put, when an external function is defined inside a function, if the internal function uses some variables of the external function, these variables cannot be recycled even if the external function is executed, because they are stored in the properties of the internal function instead.

There is another point of knowledge, all functions defined in the external function share a closure, that is, function b uses the external function a variable, even if function c does not use it, but function c will still store the a variable, this is called shared closure

Back to this question

Because in the replaceThing function, the literal object created internally is manually assigned to the global variable, and this object also has a someMethod method, so the someMethod method stores the replaceThing variable because of the closure feature.

Although someMethod does not use any local variables, there is an unused function inside replaceThing. This function uses the local variable o. Because of the shared closure, someMethod also stores o.

And o also stores the value of the global variable t before it is replaced, so every time a function is called, someone will hold the internal variable o, so it cannot be recycled. To solve this memory leak, you need to cut off the holder of o so that the local variable o can be recycled normally.

So there are two ideas: either let someMethod not store o; or release o after using it;

If the unused function is useless, you can directly remove the function and see the effect:

The reason why the memory is rising in a ladder-like manner here is that the current memory is still sufficient and the garbage collection mechanism has not been triggered. You can manually trigger the GC, or run it for a while and wait until the GC works to check whether the memory drops to the initial state. This indicates that all the memory can be recycled.

Or you can pull a memory snapshot to see that when you pull a snapshot, GC will be forced to be performed automatically before pulling the snapshot:

Right? Even if the replaceThing function is called periodically, the local variable o in the function stores the value of the previous global variable t, but it is a local variable after all. After the function is executed, if there is no external reference to it, it can be recycled, so in the end, only the object stored in the global variable t will remain in the memory. Of course, if the unused function cannot be removed, then you can only remember to release the o variable manually after using it:

var unused = function() {
    if (o) {
      console.log("hi")
      o = null;
    }        
}

But this approach does not cure the root cause, because before the unused function is executed, this pile of memory still exists and is still leaking and cannot be recovered. The difference from the beginning is that at least after the unused function is executed, it can be released.

In fact, we should consider whether there are any problems with the code here, why local variables are needed for storage, why the unused function is needed, and what is the purpose of this function? If it is just to determine whether the previous global variable t is available at some point in the future, then why not just use another global variable to store it? Why choose a local variable?

Therefore, when writing code, you should pay special attention to scenarios involving closures. If used improperly, it is likely to cause some serious memory leaks. You should remember that closures allow functions to hold external lexical environments, causing some variables in the external lexical environment to be unable to be recycled, and there is also the feature of sharing a closure. Only by understanding these two points can you correctly consider how to implement closures when it comes to usage scenarios to avoid serious memory leaks.

Summarize

This concludes this article about js memory leak scenarios, how to monitor and analyze them. For more information about js memory leak scenario monitoring, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!