JavaScript also talks about memory optimization _ javascript skills

This article mainly introduces the JavaScript Memory optimization, mainly because javascript applications are getting more and more complex, and memory problems such as choppy and memory overflow become no stranger, so we also talk about memory optimization, for more information, see C/C ++. The processing of JavaScript in memory has made us pay more attention to writing business logic in development. However, as the business continues to become more complex and the development of single-page applications, mobile HTML5 applications, and Node. js programs, the memory problems in JavaScript cause freezing and memory overflow.

This article will discuss memory usage and optimization at the JavaScript language level. From the aspects that you are familiar with or have heard of, to what you will not notice most of the time, we will analyze them one by one.

1. Language-level memory management

1.1 Scope

Scope is a very important operating mechanism in JavaScript programming. In synchronous JavaScript programming, it does not fully attract the attention of beginners, but in asynchronous programming, good scope control skills have become essential skills for JavaScript developers. In addition, the scope plays a vital role in JavaScript Memory Management.

In JavaScript, function calls, with statements, and global scopes can be formed.

Take the following code as an example:

The Code is as follows:

Var foo = function (){
Var local = {};
};
Foo ();
Console. log (local); // => undefined

Var bar = function (){
Local = {};
};
Bar ();
Console. log (local); // => {}

Here we define the foo () function and bar () function. Their intention is to define a variable named local. However, the final results are quite different.

In the foo () function, we use the var statement to declare and define a local variable. Because the function body has a scope, this variable is defined in this scope. In addition, the foo () function does not perform any extended scope processing. Therefore, after the function is executed, the local variable is destroyed. In the outer scope, the variable cannot be accessed.

In the bar () function, the local variable is not declared using the var statement. Instead, the local variable is directly defined as a global variable. Therefore, the variable can be accessed in the outer scope.

The Code is as follows:

Local = {};
// The definition here is equivalent
Global. local = {};

1.2 Scope chain

In JavaScript programming, you will certainly encounter multi-layer function nesting scenarios, which are representative of a typical scope chain.

As shown in the following code:

The Code is as follows:

Function foo (){
Var val = 'hello ';

Function bar (){
Function baz (){
Global. val = 'World ;'
}
Baz ();
Console. log (val); // => hello
}
Bar ();
}
Foo ();

According to the previous description about the scope, you may think that the result of the code here is world, but the actual result is hello. Many beginners will be confused here, so let's take a look at how this code works.

In JavaScript, variable identifiers are searched outward from the current scope until the global scope. Therefore, access to variables in JavaScript code can only be performed externally, but cannot be reversed.

The execution of the baz () function defines a global variable val in the global scope. When accessing the val identifier in the bar () function, according to the principle of searching from the inside out to the outside: If the val identifier is not found in the scope of the bar function, it goes to the upper layer, that is, to search for the scope of the foo () function.

However, the key to making everyone confused is here: this access to the identifier finds the correct variable in the scope of the foo () function, so it will not continue to look out, so it is in the baz () the global variable val defined in the function does not affect the variable access.

1.3 Closure

We know that the identifier search in JavaScript follows the principle from inside to outside. However, with the complexity of business logic, a single transmission order is far from meeting the increasing new demands.

Let's take a look at the following code:

The Code is as follows:

Function foo (){
Var local = 'hello ';
Return function (){
Return local;
};
}
Var bar = foo ();
Console. log (bar (); // => Hello

The technology shown here to allow the outer scope to access the inner scope is Closure ). Thanks to the application of higher-order functions, the scope of the foo () function is "extended 』.

The foo () function returns an anonymous function, which exists in the scope of the foo () function. Therefore, you can access the local variable within the scope of the foo () function, and save its reference. Because this function directly returns the local variable, you can directly execute the bar () function in the outer scope to obtain the local variable.

Closure is an advanced feature of JavaScript. We can use it to achieve more complex effects to meet different needs. Note that the function with internal variable reference is taken out of the external function, so the variables in the scope are not necessarily destroyed after the function is executed, until all references to internal variables are removed. Therefore, applications with closures can easily cause memory to be released.

2. Memory collection mechanism of JavaScript

Here I will use Chrome and Node. the V8 engine launched by Google is used as an example to briefly introduce the memory recycle mechanism of JavaScript. For more details, you can buy my good friend park Ling's book, "a simple introduction to Node. js, in which the "memory control" chapter has a very detailed introduction.

In V8, all JavaScript objects are allocated memory through heap.

When we declare a variable in the Code and assign a value, V8 will allocate a part of the variable to the heap memory. If the applied memory is insufficient to store this variable, V8 will continue to apply for memory until the heap size reaches the V8 memory limit. By default, the maximum heap memory size of V8 is 1464 MB in 64-bit systems, and 732 MB in 32-bit systems, that is, about 1.4 GB and 0.7 GB.

In addition, V8 manages the JavaScript objects in heap memory by generation: New Generation and old generation. A new generation is a JavaScript Object with a short life cycle, such as temporary variables and strings. The old generation is an object with a long life cycle after multiple garbage collection, such as the master controller and Server Object.

Garbage collection algorithms have always been an important part of programming language development. The garbage collection algorithms used in V8 mainly include the following:

1. Scavange algorithm: memory space management through replication, mainly used for new generation of memory space;
2. the Mark-Sweep algorithm and the Mark-Compact algorithm organize and recycle the heap memory by marking. They are mainly used to check and recycle the old generation objects.

PS: More detailed V8 garbage collection implementation can be learned by reading relevant books, documents and source code.

Let's take a look at under what circumstances the JavaScript engine will recycle objects.

2.1 Scope and reference

Beginners often mistakenly believe that when the function is executed, the objects declared inside the function will be destroyed. However, this understanding is not rigorous and comprehensive, and can be easily confused.

Reference is a very important mechanism in JavaScript programming, But it is strange that General developers do not pay attention to it or even understand it. Reference refers to the abstract relationship of "code access to objects", which is similar to the pointer of C/C ++, but not the same. References are also the most critical mechanism of the JavaScript engine in garbage collection.

The following code is used as an example:

The Code is as follows:

//......
Var val = 'Hello world ';
Function foo (){
Return function (){
Return val;
};
}
Global. bar = foo ();
//......

After reading this code, can you tell me which objects are still alive after the code is executed?

According to relevant principles, objects not released in this Code are val and bar (). What makes them unable to be recycled?

How does the JavaScript engine collect garbage? The garbage collection algorithm mentioned above is only used for garbage collection. How does it know which objects can be recycled and which objects need to survive? The answer is a reference to a JavaScript Object.

In JavaScript code, even if you simply write a variable name as a single row without any operation, the JavaScript engine will regard it as an access behavior to the object, and there is a reference to the object. To ensure that garbage collection does not affect the running of the program logic, the JavaScript engine must not recycle the currently used objects. Otherwise, it will be messed up. Therefore, the criterion used to determine whether an object is in use is whether the object is still referenced. But in fact, this is a compromise. Because JavaScript references can be transferred, some references may be brought to the global scope, but in fact, there is no need to access it in the business logic, and it should be recycled, but the JavaScript engine still holds that the program still needs it.

How to Use variables and references in the correct posture is the key to optimizing JavaScript at the language level.

3. Optimize Your JavaScript

Finally, I am very grateful to you for your patience. After so many introductions, I believe you have a good understanding of the JavaScript Memory Management mechanism, the following tips will make you feel better.

3.1 make good use of functions

If you have the habit of reading excellent JavaScript projects, you will find that many Daniel often uses an anonymous function to wrap the code at the outermost layer when developing the front-end JavaScript code.

The Code is as follows:

(Function (){
// Main business code
})();

Some are even more advanced:

The Code is as follows:

; (Function (win, doc, $, undefined ){
// Main business code
}) (Window, document, jQuery );

Even front-end modular loading solutions such as RequireJS, SeaJS, and OzJS all adopt similar forms:

The Code is as follows:

// RequireJS
Define (['jquery '], function ($ ){
// Main business code
});

// SeaJS
Define ('m odule', ['dep', 'underscore '], function ($ ,_){
// Main business code
});

If you say that the Code of many Node. js open-source projects is not handled in this way, you will be wrong. Before running the code, Node. js packs each. js file into the following format:

The Code is as follows:

(Function (exports, require, module, _ dirname, _ filename ){
// Main business code
});

What are the benefits of doing so? We all know that at the beginning of this article, JavaScript can form function calls, with statements, and global scopes. We also know that objects defined in the global scope will probably survive until the process exits. If they are large objects, it will be troublesome. For example, some people like to make template rendering in JavaScript:

The Code is as follows:

$ Db = mysqli_connect (server, user, password, 'myapp ');
$ Topics = mysqli_query ($ db, "SELECT * FROM topics ;");
?>




Are you a monkey?