Javascript memory leak principle
1. What is a memory leak?
A memory leak is when memory allocated to an application cannot be reallocated. A piece of allocated memory can neither be used nor reclaimed, and a memory leak will occur until the browser process ends. In C++, because memory is managed manually, memory leaks are a common occurrence. Now popular languages such as C# and Java use automatic garbage collection methods to manage memory, and almost no memory leaks occur under normal use. The browser also uses the automatic garbage collection method to manage memory, but due to bugs in the browser garbage collection method, memory leaks will occur.
Normally, the garbage collector recycles DOM elements and event handlers when they are not referenced or accessed. However, memory leaks were prone to occur in earlier versions of IE (IE7 and earlier) because the memory manager did not understand the Javascript lifecycle properly and would not reclaim memory until the lifecycle was broken (which could be achieved by assigning to null).
2. Why do you need to pay attention to memory leaks?
Memory leaks are a common accidental programming error in large web applications. Memory leaks can slow down the performance of a web application until more memory is wasted than the system can allocate, and the application will not be able to use it. As a web developer, developing an application that meets functional requirements is only the first step. Performance requirements are as important as the success of the web application, not to mention that it may cause application errors or browser crashes.
3. What are the main reasons for memory leaks in Javascript?
1) Circularly referencing
the object instance generated by the COM component of the IE browser and the object instance generated by the web script engine refer to each other, which will cause memory leaks. This is also the most common and major leak we encounter in web pages;
A very simple example: a DOM object that is referenced by a Javascript object and at the same time references the same or other Javascript object, this DOM object may cause a memory leak. References to this DOM object will not be collected by the garbage collector when the script stops. To break a circular reference, the object that refers to the DOM element or the reference to the DOM object needs to be assigned null.
2) Javascript closures
Many implementations rely on Javascript not wrapping due to Javascript scoping, check out my previous article JavaScript Scope and Closure if you want to learn more about closures.
Closures can cause memory leaks because the inner method keeps a reference to the outer method variable, so even though the method returns the inner method can continue to access private variables defined in the outer method. The best practice for Javascript programmers is to disconnect all event handlers before the page reloads.
3) DOM insertion order
A temporary object is created when 2 DOM objects of different scopes are added together. When the DOM object changes scope to document, that temporary object is useless. That is, DOM objects should be added in order from the topmost DOM element that exists on the current page to the remaining DOM elements, so that they always have the same scope and no temporary objects are created.
4) Internal function references (Closures) - Closures can be seen as a special form of looping applications that are currently causing a lot of problems. Due to the dependence on the specified keywords and grammatical structure, the Closures call is easier to be found by us;
5) Cross-Page Leaks - Cross-Page Leaks are actually smaller leaks, usually during your browsing process, due to internal object thinning. Below we will discuss the issue of DOM insertion order, in that example you will find that with only a few code changes, we can avoid the impact of object thinning on object construction;
6) Pseudo-Leaks - This is not a real leak, but if you don't know about it, you may get extremely depressed when your available memory resources become less and less. To demonstrate the problem, we will cause a large memory "leak" by overriding the contents of the Script element.
For the principle of leakage, you can refer to a technical article on Microsoft's website, "Understanding and Solving Internet Explorer Leak Patterns". To put it bluntly, because Dom and javaScript use different garbage collection mechanisms, various leaks have occurred. It should be noted that basically the leaked code that appears on IE will not appear in FireFox. The component of IE browser is basically a COM component, which uses counted recycling. FireFox does a better job in this regard, but I found that even without Leaks, but FireFox will have slow response and high CPU after running for a while