Understanding and solving IE Memory leakage [translation]

This article has been read for some days, and some recent development efforts are trying to follow the principles in this article. However, the current situation is that after the code size is slightly larger, the memory leakage of IE is still very serious, so I am very angry (there is no consequence) that I should dig this article out for approval. In order to facilitate the evaluation, I decided to translate it into Chinese first. After the intensive reading, I found that the description and avoidance of each leak scene were almost always done by the author, so it seems that the article is correct again, there is no approval. It just reminds me of Liu Yishou...

Author: Justin Rogers, Micrsoft Corporation June 2005
Translator by: http://birdshome.cnblogs.com

Development of Web development

In the past, Web developers did not focus much on memory leaks. At that time, the relationship between pages was relatively simple, and different connection addresses were mainly used to navigate in the same site. This design method is very helpful for the browser to release resources. Even if a Web page is running with a resource leak, its impact is very limited and is often ignored.

Today, people have higher requirements for Web applications. A page may not jump to a URL for several hours and dynamically update the page content through the Web service. The extensive use of complex event Association design, Object-based JScript, and DHTML technologies has allowed the code to reach its limits. In this case and change, it is very urgent to find out the memory leakage method, especially in the past, these problems have been blocked by the traditional page navigation method.

The good thing is that when you specify what you want to find, the memory leakage method is relatively easy to determine. Most of the leaks you may encounter are known, and you only need a small amount of extra work to bring you benefits. Although a small number of small leaks still occur on some pages, the main problems are still easy to solve.

Leakage Method

In the following content, we will discuss the memory leakage methods and provide examples for each method. An important example is Closure technology in JScript, and another example is to use Closures in event execution. When you are familiar with this example, you can find and modify most of your existing Memory leakage problems, but other Closure-related problems may be ignored.

Now let's take a look at the following methods:

1. The object instances generated by the COM component of the IE browser and the object instances generated by the web script engine will reference each other, causing memory leakage. This is also the most common and major Web page leakage method;

2. Internal function reference (Closures)-Closures can be seen as a special form of loop applications that cause a large number of problems. Closures calls are easily discovered because of the specified keywords and syntax structure;

3. Cross-Page Leaks (Cross-Page Leaks)-in fact, Cross-Page leakage is a small leak, which is usually caused by the internal object thin meter during your browsing process. Next we will discuss the DOM insertion sequence. In that example, you will find that you only need to modify a small amount of code, so that we can avoid the impact of object thinning on Object Construction;

4. It seems that the leakage (Pseudo-Leaks) is not a real leak, but if you do not know it, you may be extremely depressed when your available memory resources become fewer and fewer. To demonstrate this problem, we will overwrite the content in the Script element to cause a large amount of memory leakage ".

Loop reference

Loop reference is basically the start of all leaks. Generally, the script engine processes cyclic references through the garbage collector (GC), but some unknown factors may prevent the release of resources from the environment. For IE, the status of some DOM object instances is unknown to the script. The following are their basic principles:

Figure 1: Basic cyclic Reference Model

The leakage caused by this model is based on the reference count of COM. The script engine object maintains reference to the DOM object and waits for all references to be removed before the DOM object pointer is cleared and released. In our example, our script engine object has two references: The Script Engine scope and the expando attribute of the DOM object. When the script engine is terminated, the first reference will be released. DOM object reference will not be released because it is waiting for the release of the script prepare. You may think that it is very easy to detect and fix such problems, but in fact such basic examples are just the tip of the iceberg. You may have a circular reference at the end of 30 object chains. troubleshooting will be a nightmare.

If you still don't know how this leakage method works in HTML code, you can use a global script variable and a DOM object to trigger and display it.

<Html>
<Head>
<Script language = "JScript">
Var myGlobalObject;
Function SetupLeak ()
{
// First set up the script scope to element reference
MyGlobalObject = document. getElementById ("LeakedDiv ");

// Next set up the element to script scope reference
Document. getElementById ("LeakedDiv"). expandoProperty = myGlobalObject;
}

Function BreakLeak ()
{
Document. getElementById ("LeakedDiv"). expandoProperty = null;
}
</Script>
</Head>
<Body onload = "SetupLeak ()" onunload = "BreakLeak ()">
<Div id = "LeakedDiv"> </div>
</Body>
</Html>

You can use the direct null Value Method to destroy the leakage. If a null value is assigned before the page document is detached, the script engine will know that the reference chain between objects is gone. Now it can normally clear references and release DOM objects. In this example, as a Web developer, you have learned more about the relationship between objects.

As a basic case, circular references may have more complex manifestations. For object-based jscripts, a common usage is to expand DOM objects by encapsulating JScript objects. During the construction process, you often put references to DOM objects into JScript objects, and also store references to newly created JScript objects in DOM objects. Your application mode is very convenient for mutual access between two objects. This is a very direct loop reference problem, but it may not concern you because you use unused syntax forms. It may be more complicated to break the loop. Of course, you can also use simple examples for a clear discussion.

<Html>
<Head>
<Script language = "JScript">

Function Encapsulator (element)
{
// Set up our element
This. elementReference = element;

// Make our circular reference
Element. expandoProperty = this;
}

Function SetupLeak ()
{
// The leak happens all at once
New Encapsulator (document. getElementById ("LeakedDiv "));
}

Function BreakLeak ()
{
Document. getElementById ("LeakedDiv"). expandoProperty = null;
}
</Script>
</Head>
<Body onload = "SetupLeak ()" onunload = "BreakLeak ()">
<Div id = "LeakedDiv"> </div>
</Body>
</Html>

The more complicated method is to record all the objects and properties that need to be removed from the reference, and then clean up them when the Web document is uninstalled. However, in most cases, you may cause additional leaks, but it does not solve your problem.

To be continued...

// Closure I did not flip it. It is an internal function and can access the variables of the parent function. Someone turns it into a Closure and is scolded.