This vulnerability may cause JavaScript Memory leakage in several aspects.

This vulnerability may cause JavaScript Memory leakage in several aspects.

Published in Google WebPerf (London WebPerf group) in August 26, 2014.

Efficient JavaScript Web applications must be smooth and fast. Any application that interacts with the user needs to consider how to ensure the effective use of memory, because if the consumption is too large, the page will crash and force the user to reload. You can only hide in the corner and cry.

Automatic garbage collection cannot replace effective memory management, especially in large, long-running Web applications. In this lecture, we will demonstrate how to effectively manage the memory through Chrome's DevTools.

Learn how to solve performance problems, such as memory leakage, frequent garbage collection pauses, and overall memory expansion, which truly consumes your energy.

Addy Osmani shows many examples of Memory leakage in Chrome V8 in his PPT:

1) Deleting an Object attribute slows down the Object (15 times more memory consumption)
Copy codeThe Code is as follows:
Var o = {x: 'y '};
Delete o. x; // at this time, o will become a slow object.
O. x ;//

Var o = {x: 'y '};
O = null; // this should be the case

2) Closure

When a variable outside the closure is introduced to the closure, the object cannot be garbage collection (GC) when the closure ends ).
Copy codeThe Code is as follows:
Var a = function (){
Var largeStr = new Array (1000000). join ('x ');
Return function (){
Return largeStr;
}
}();

3) DOM Leakage

When the original COM is removed, the sub-node reference cannot be recycled if it is not removed.
Copy codeThe Code is as follows:
Var select = document. querySelector;
Var treeRef = select ('# tree ');

// In the COM tree, leafRef is a subnode of treeFre.
Var leafRef = select ('# leaf ');
Var body = select ('body ');

Body. removeChild (treeRef );

// # Tree cannot be returned because treeRef is still
// Solution:
TreeRef = null;

// Tree cannot be recycled because leafRef
LeafRef = null;

// Now # the tree can be released.

4) leakage of Timers Timer

The timer is also a common cause of Memory leakage:
Copy codeThe Code is as follows:
For (var I = 0; I <90000; I ++ ){
Var buggyObject = {
CallAgain: function (){
Var ref = this;
Var val = setTimeout (function (){
Ref. callAgain ();
},90000 );
}
}

BuggyObject. callAgain ();
// Timer is still
BuggyObject = null;
}

5) debugging memory

Chrome's built-in memory debugging tool allows you to conveniently view memory usage and Memory leakage:
In Timeline-> Memory, click record:

For more information, see the original PPT.

Does javascript also cause memory leakage?

The simplest Memory leakage:
Function (){
Document. body. style. background = 'red ';
}
We know that this function object is always in the memory after the function is declared, which is a relatively simple memory leak;
You can destroy it as follows:
For example, after execution:
A ();
A = null;
It seems you can. Set A to null.

How does javascript solve an instance of Memory leakage?

First, you need to correct/understand the so-called closure. For more information, see my answer here: zhidao.baidu.com/question/586170392.html? Oldq = 1

After you have clearly understood the closure, you will find the problem by looking at the code above.
Element. onclick = function () {alert (element. id);} Here, The onclick of the element object points to your anonymous function, so we can first make it clear that before the element Object is released, your anonymous function cannot be released.
The problem is, can an element object be released at a certain time in the future? No! Because your anonymous function references the element Object again!
That is to say, the element Object references your anonymous function, and your anonymous function references the element. The results form a circular reference. This is the problem.

In this case, memory leakage occurs. However, it is not necessary to study it carefully. Although circular references are formed here, the modern garbage collector does not simply check whether the reference count of an object is 0 to determine whether it can be recycled. It depends on whether there is a path from the root object to the object. Simply put, for the modern garbage collector, such a simple ring reference will not cause memory leakage.