What should I do if the web application gets stuck more and more?

Introduction

If your web application gets stuck more and more, you have reason to suspect that there is a memory leak.
When developing web applications, you often encounter memory leaks, which may cause the performance of the application to degrade or crash. Chrome offers a memory panel that can help us identify and fix these issues. This article will introduce how to use Chrome's Memory panel for memory analysis, and provides some common memory leak causes and solutions.

Open Chrome's Memory panel

  1. Use the Chrome browser to open the webpage you want to debug.
  2. Press F12(Windows) or Command + Option + I(Mac) to open Chrome's developer tools.
  3. In the developer tools, switch to the "Memory" tab.

How to analyze memory leaks

1. Record memory snapshot

On the Memory panel, click the red circular button, it will record the memory status of the current page.  You can repeat this step to record multiple snapshots as needed.

2. Find the memory increase operation

By operating the page, observe the change of the memory value, and find out the operation that has a great impact on the memory. At the same time, it should be noted that there must be a memory leak when the memory increases. For example, if your dom increases, the natural memory will become larger. If found, Components or pages have been destroyed, and after waiting for a period of time, if the memory has not dropped, you can record the current memory snapshot for comparison.

3. Compare memory snapshots

On the Memory panel, select the snapshots to compare. A list of memory snapshots you recorded will be displayed here. Select two snapshots to compare to see the differences between them.
insert image description here

4. Look for possible leaks

Distance (distance): Indicates the shortest path length from the root object to the selected object. It reflects the depth of the reference relationship between the selected object and the root object.

Shallow Size (shallow size): Indicates the memory size occupied by the selected object itself, excluding other objects referenced by it.

Retained Size: Represents the sum of the memory occupied by the selected object and all directly or indirectly referenced objects. It is calculated by using the garbage collection algorithm, that is, even if some objects do not have direct references pointing to them, their memory will be preserved since they can still be accessed through other means.

How to judge memory leaks based on these properties?
In general, you can judge that there may be a memory leak problem according to the following guidelines:

If the Distance (distance) of an object is large, it means that the reference chain between the object and the root object is long, and there may be a memory leak. Further checks are needed to see if the object and other objects it references can be garbage collected gracefully.

If the Shallow Size of an object is very large, it means that the object itself takes up a lot of memory. This may be normal, such as a large array or image, etc., but it may also be one of the causes of memory leaks. Need to combine other indicators for further judgment.

If an object's Retained Size (retained size) far exceeds its Shallow Size (shallow size), it means that the object and other objects it refers to retain a large amount of space in memory. In this case, there is likely to be a memory leak, and it is necessary to further check the reference relationship between objects to determine whether there are unnecessary references that cause the memory to fail to be released normally.

In addition, it can be judged by the number behind the object. If the number of an object keeps increasing, it needs to be further judged whether there is an unreleased situation. Finally, the specific
object can be viewed by clicking on the file that generated it. The specific generation logic can be further checked for leaks. reason

Guess you like

Origin blog.csdn.net/weixin_42657666/article/details/132233556