How to avoid JS memory leaks?

[[416172]]

Many developers may not care about whether there is memory leak in the pages they maintain. The reason may be that the memory leak of simple pages is very slow at the beginning, and the page may be refreshed by the user before causing serious lag, so the problem is hidden. However, as the page becomes more and more complex, especially when your page is interactive in SAP mode, the hidden danger of memory leak becomes more and more serious, until suddenly one day a user reports: "The page gets stuck after operating for a while, and I don't know why. It was not like this before."

This article introduces the methods of investigating memory leaks through some simple examples, summarizes the causes and common situations of memory leaks, and summarizes how to avoid memory leaks for each situation. I hope it will be helpful to everyone.

A simple example

Let's take a look at a simple example. Here is the code for this example:

Code 1

The logic of code 1 is very simple: when you click the "add date" button, 3000 new Date objects will be pushed into the dateAry array, and when you click the "clear" button, dateAry will be cleared. Obviously, the "add date" operation will cause the memory usage to continue to grow. If this logic is used in actual applications, it will cause memory leaks (not considering the case where the code logic is deliberately designed like this). Let's see how to investigate the cause of this memory growth and how to find the memory leak point.

1 heap snapshot

To avoid interference from browser plug-ins, we open the above code in a new incognito window in Chrome. Then find the "Heap Snapshot" tool in the Memory tool in Chrome's devtools, click the record button in the upper left corner to record a Snapshot, then click the "add date" button, and after manually triggering GC (Garbage Collect), record another Snapshot. Repeat the above operations several times to obtain a series of Snapshots as shown in Figure 1.

Figure 2 Recorded Snapshot Group

Referring to [Code 1], we can see that when the "add date" button is clicked, 3000 new Date objects will be pushed into the dateAry array. On the right side of the Date constructor in Figure 2, we can see these 3000 Date objects (Date x 3000), which correspond to the 3000 Date objects created by our loop. Based on the above operations, we can know that the Memroy Heap Snapshot tool in chorome devtools can record all memory objects at a certain moment, that is, a "snapshot". The snapshot is grouped by "constructor" and shows all recorded JS objects.

If this page is a page on a website that actually serves users (users may click the "add date" button very frequently, and the author may want to record the number of times users click? Maybe, although I don't know why he would do that), as the user's usage time increases, the response of the "add date" button will become slower and slower, and the overall page will become increasingly stuck. In addition to the system's memory resources being occupied, the frequency and duration of GC are also increasing. As shown in Figure 3, because the execution of JS is suspended during the execution of GC, the page will appear to be increasingly stuck.

Figure 3 GC ratio recorded by Performance

Figure 4 Chrome's Task Manager

final:

Figure 5: Excessive memory usage causes the browser to crash

So, in this "real" scenario, how can we find the 3,000 Date objects that are "causing trouble"? The first thing that comes to our mind should be: Didn't we record many snapshots before? Can we compare them to find the "differences" and find the growth from the differences? The idea is very correct. Before that, let's analyze these snapshots again: every time you click the "add date" button and manually trigger GC, the size of the snapshot obtained is larger than the previous one. If this memory growth phenomenon does not meet the "expectation" (obviously it does not meet the expectation in this "real" example), then there is a strong suspicion of memory leak.

At this time, we select Snapshot 2, select "Comparison" in "Summary" as shown in Figure 2, and select Snapshot 1 in "All objects" on the right. In this way, the display in Constructor is a comparison of Snapshot 1 and Snapshot 2. It is not difficult to find that +144KB in the figure is the most suspicious, so we select its constructor Date, expand and select any sub-item to see the details, and find that it is held by dateAry constructed by the Array constructor (that is, a member of dateAry), and dateAry is held in three places. We don't need to pay attention to the array inside the system. The place with "context in ()" in Figure 6 gives us the location of the context holding dateAry. Click it to jump to the location of the code. The whole operation is shown in Figure 6:

Figure 6 Positioning code location

There is one thing worth noting here, the "()" in "context in () @449305" in Figure 6 is displayed as "()" because an "anonymous function" is used in the code (the arrow function in line 2 of Code 2):

 // [Write date ] pushDate.addEventListener( "click" , () => { dateCount.innerHTML = `${++dateNum}`; for (let j = 0; j < 3000; ++j) { dateAry.push(new Date ()); }});

Code 2 Anonymous function

But if we give the function a name, as shown in the code below, that is, if we use a named function (function add in line 2 of code 3) or assign the function to a variable and use the variable (behavior in lines 10 and 18), we can see the name of the corresponding function in devtools, which can help us better locate the code, as shown in Figure 7.

 // [Write date] pushDate.addEventListener("click", function add() { dateCount.innerHTML = `${++dateNum}`; for (let j = 0; j < 3000; ++j) { dateAry.push(new Date()); }}); const clear = document.querySelector(".clear"); const doClear = function () { dateAry = []; dateCount.innerHTML = "0";}; // [Recycle memory] clear.addEventListener("click", doClear);  

Code 3 named function

Figure 7 Named functions facilitate positioning

In this way, we have found the suspicious parts of the code. We only need to catch the author of the code and "analyze" him to basically figure out the memory leak problem.

In fact, in addition to "Comparison", Snapshot has another more convenient entry for comparison. Here you can directly see the memory allocated between the two time points of recording Snapshot 1 and Snapshot 2. This method can also locate the suspicious Date x 3000:

Figure 8 Snapshot comparator

The above document introduces the method of using Heap Snapshot to find memory leaks. The advantages of this method are: you can record multiple Snapshots and then compare them two by two. You can also see the full amount of memory in the Snapshot, which is not available in the "Allocation instrumentation on timeline" method to be discussed below. In addition, this method can more easily find memory leaks caused by Detached Dom, which will be discussed later.

2 Allocation instrumentation on timeline

However, do you think that this high-frequency recording of snapshots, comparisons, and re-comparisons is a bit troublesome? I need to keep clicking "add date", and then the mouse has to go over to click manual GC, record snapshots, wait for the recording to be completed, and then operate again, and then record again. Is there a simpler way to find memory leaks? At this time, we return to the original interface of Memory, and you suddenly find that there is a radio under "Heap snapshot": "Allocation instrumentation on timeline", and the last part of the introduction text under this radio says: "Use this profile type to isolate memory leaks". It turns out that this is a tool specifically used to investigate memory leaks! So, we select this radio, click the start recording button, and then focus on the page, and then you will find that when you click the "add date" button, the timeline recorded on the right will have an extra heartbeat:

Figure 9 Allocation instrumentation on timeline

As shown in Figure 9, every time we click the "add date" button, there is a corresponding heartbeat on the right. When we click the "clear" button, all the heartbeats that just appeared will "retract". So we conclude that each "heartbeat" is a memory allocation, and its height represents the amount of memory allocation. In the subsequent time, if the allocated memory corresponding to the heartbeat just now is recycled by GC, the "heartbeat" will change to the height after recycling. Therefore, we get rid of the dilemma of operating and recording back and forth in Snapshot. We only need to focus on the operation of the page and observe which operation is suspicious in the timeline changes on the right.

After a series of operations, we found that the click behavior of the "add date" button is suspicious, because the memory allocated by it will not be automatically recycled, that is, as long as it is clicked once, the memory will increase a little. We stopped recording and got a timeline snapshot. At this time, if we click a heartbeat:

Figure 10 Click on a heartbeat

The familiar Date x 3000 appears again (Figure 11). Click a Date object to view the holding chain. The following steps are the same as the holding chain analysis of the Snapshot above:

Figure 11 Finding the leak point through the timeline

The advantages of this method have been explained above. It can be very intuitive and convenient to observe the memory allocation and recovery process with suspicious operations, and it can be convenient to observe the memory allocated each time. Its disadvantages: when the recording time is long, it will take a long time for devtools to collect the recording results, and sometimes even freeze the browser; detached DOM will be discussed below. This tool cannot compare detached DOM, but heap snapshot can.

3 performance

There is also a Memory function in the Performance panel of devtools. Let's see how to use it. We check Memory and record a performance result:

Figure 12 Performance recording process

As can be seen in Figure 12, during the recording process we clicked the "add date" button 10 times in succession, then clicked the "clear" button once, and then clicked "add date" 10 times again. The final result is shown in Figure 13:

Figure 13 Performance recording results

In Figure 13 we can get the following information:

Memory trend during the entire operation: See the lower part of Figure 13. During the first round of 10 clicks, the memory keeps growing. After clicking clear, the memory drops drastically. After the second round of 10 clicks, the memory keeps growing again. This is also the main function of this tool: to get the memory trend chart of suspicious operations. If the memory keeps rising, there is reason to suspect that this operation may be caused by memory leak.
Memory growth: Refer to the JS Heap position. You can see the memory growth/decrease at each step by hovering the mouse. By locating a "step" in the timeline, we can also find suspicious code, as shown in Figure 14:

Figure 14 Locating the problem code through Performance

Advantages of this method: You can intuitively see the overall trend of memory, and get information such as function call stack and time during all operations. Disadvantages: There are no specific details of memory allocation, and the memory allocation process cannot be seen in real time during the recording process.

2. Scenarios where memory leaks occur

1 Global

JS uses the mark-and-sweep method to recycle inaccessible memory objects. The memory occupied by attributes mounted on the global object (the window object in the browser, called the root node from the perspective of garbage collection, also called GC root) will not be recycled because it is always accessible, which is in line with the naming meaning of "global".

The solution is to avoid using global objects to store large amounts of data.

2 Closure

We can slightly modify [Code 1] to get a version where closure causes memory leak:

Code 3: Closure causes memory leak

Load the above code into Chrome and record a Snapshot using the timeline method. The result is shown in Figure 15:

Figure 15 Closure recording results

We select the heartbeat with index = 2, and you can see a "(closure)" in the Constructor. We expand the closure and see the "inner()" inside. The "()" after inner() indicates that inner is a function. You may ask, "The Retained Sizes of the Constructors in the figure are all similar, why did you choose (closure)?" It is precisely because there is no Retained Size with a significantly higher proportion that we randomly choose a survey. Later, you will find that no matter which one you choose, the final survey link will lead to the same result.

Let's look at the details of inner() in the Retainers below: From the Retainers below, we can see that the inner() closure is the second item of an Array (index starts at 0), and the holder of this array is ary in system/Context (i.e. global). By observing, we can see that the retained size of ary is 961KB, which is approximately equal to 5 times of 192KB. 5 is the number of times we clicked the "add date" button, and the following 5 "previous in system/Context" are each 192KB in size, and they are ultimately held by a inner() closure. So far, we can conclude that there is an ary array in the global world, and its main memory is filled by inner(). By locating the code location through the blue code entry at index.html:xx, we can see everything. It turns out that the inner() closure holds a large object, and all inner() closures and their large objects are held by the ary object, and ary The object is global and will not be recycled, resulting in a memory leak (if this behavior is not as expected). Go back and select the system/Context constructor mentioned above, you will see (see Figure 16, familiar):

Figure 16 system/Context

That is, the system/Context you selected is actually the context object of the inner() closure, and this context holds 192KB of memory. The blue index.html:xx can be used to locate the problem code. If you select the Date constructor to view as shown in Figure 17, you can also locate the problem. Here, the analysis process is left to the readers:

Figure 17 Select the Date constructor

3 Detached DOM

Let's take a look at the following code and load it with Chrome:

Code 4 Detached Dom

Then we use the Heap Snapshot method to record the two snapshots before and after clicking the "del" button, and the result is shown in Figure 6. We choose the comparison method with snapshot 1 and enter "detached" in the filter of snapshot 2. We observe the "Delta" column of the filtered results, and the columns that are not 0 are as follows:

To explain the above table, we need to introduce a knowledge point: DOM objects need to meet two conditions at the same time to be recycled: 1. DOM is deleted in the DOM tree; 2. DOM is not referenced by JS objects. The second point is easy to be overlooked. As shown in the above example, Detached HTMLButtonElement +1 means that a button DOM has been deleted from the component tree, but there is still a JS reference to it (we do not consider intentional cases).

Similarly, Detached EventListener is also detached because the DOM is deleted, but the event is not unbound. The solution is also very simple: just unbind the event in time.

So the solution is very simple: see code 5, the temporary variable will be recycled when the callback function del is executed, so both conditions are met at the same time, the DOM object will be recycled, the event will be unbound, and the Detached EventListener will no longer exist. It is worth noting that for table elements, if a td element is detached, the entire table will not be recycled because it references the table it is in.

Code 5 Detached DOM solution

Figure 18: Snapshot of Detached DOM

Performance monitor tool

DOM/event listener leaks are very common when writing tools such as carousels, pop-ups, and toast prompts. Chrome's devtools has a Performance monitor tool that can be used to help us investigate whether there is a DOM/event listener leak in the memory. First, let's look at Code 6:

Code 6: Continuously increase the DOM NODE

Open the Performance monitor panel as shown in Figure 19:

Figure 19 Opening the Performance monitor tool

The number on the right side of DOM Nodes is the number of all DOM nodes in the current memory, including those in the current document, detached, and temporarily created during the calculation process. Every time we click the "add date" button and manually trigger GC, the number of DOM Nodes increases by 2. This is because we add a button node and a button text node to the document, as shown in Figure 20. If the toast component you wrote is temporarily inserted into the document and removed after a while and then in the detached state, the number of DOM Nodes in the Performance monitor panel will continue to increase. Combined with the snapshot tool, you can locate the problem. It is worth mentioning that some third-party library toasts have this problem. I wonder if you have been fooled.

Figure 20 Increasing DOM Nodes

4 console

Some people may not notice that the content printed in the console needs to keep the reference existing all the time. This is also worth noting, because printing too many large objects will also cause memory leaks, as shown in Figure 21 (with code 7). The solution is not to print objects to the console recklessly, but only print out necessary information.

Code 7 console causes memory leak

Figure 21 Memory leak caused by console

Conclusion

This article uses several simple examples to introduce the timing of memory leaks, methods for finding leaks, and compares the advantages and disadvantages of various methods, summarizing the points to pay attention to in avoiding memory leaks. I hope it will be helpful to readers. If there are any misunderstandings or writing errors in the article, please leave a message to correct them.

refer to

https://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art038
https://developer.chrome.com/docs/devtools/memory-problems/
https://www.bitdegree.org/learn/chrome-memory-tab