Detailed explanation of JS memory space

Overview

Variable objects and heap memory

var a = 20;
var b = 'abc';
var c = true;
var d = { m: 20 } 

For a long time, I thought that the concept of memory space was not so important in learning JS. But later, when I went back to reorganize the basics of JS, I found that due to my vague understanding of them, I didn’t understand a lot of things. For example, what are the most basic reference data types and reference passing? For example, what is the difference between shallow copy and deep copy? There are also closures, prototypes, and so on.

Therefore, I gradually realized that if I want to have a deeper understanding of JS, I must have a clear understanding of memory space.

1. Stack and Heap

Note: Stack can also be called stack

Unlike C/C++, JavaScript does not strictly distinguish between stack memory and heap memory. Therefore, we can roughly understand that all JavaScript data is stored in the heap memory. However, in some scenarios, we still need to process based on the idea of ​​stack data structure, such as JavaScript's execution context (I will summarize the execution context in the next article). The execution context logically implements the stack. Therefore, it is still very important to understand the principles and characteristics of the stack data structure.

To simply understand how the stack is accessed, we can analyze it by analogy with a ping-pong box. As shown on the left side of the picture below.

Ping-Pong Box and Stack Analogy

The way the ping-pong balls are stored is exactly the same as the way data is stored and accessed in the stack. The ping-pong ball 5 at the top layer in the box must be put in last but can be used first. If we want to use the ping-pong ball 1 at the bottom, we must take out the four ping-pong balls on top so that ping-pong ball 1 is at the top layer of the box. This is the first-in-last-out and last-in-first-out characteristics of the stack space. The figure has shown in detail the storage principle of the stack space.

The way a heap stores and accesses data is very similar to that of a bookshelf and books.

Although the books are neatly stored on the bookshelf, as long as we know the name of the book, we can easily take out the book we want, instead of taking out all the ping-pong balls from the box to get a ping-pong ball in the middle. For example, in JSON formatted data, the key-value pairs we store can be unordered, because the different order does not affect our use, we only need to care about the name of the book.

2. Variable objects and basic data types

After the JavaScript execution context is generated, a special object called a variable object is created (the details will be summarized together with the execution context in the next article). JavaScript's basic data types are often stored in the variable object.

Strictly speaking, variable objects are also stored in heap memory, but due to the special functions of variable objects, we still need to distinguish them from heap memory when understanding them.

Basic data types are simple data segments. There are 5 basic data types in JavaScript, namely Undefined, Null, Boolean, Number, and String. Basic data types are accessed by value because we can directly manipulate the actual value stored in the variable.

3. Reference data types and heap memory

Unlike other languages, JS's reference data types, such as arrays, have values ​​of unfixed size. The value of a reference data type is an object stored in heap memory. JavaScript does not allow direct access to locations in the heap memory, so we cannot directly manipulate the heap memory space of an object. When operating on an object, you are actually operating on the object reference rather than the actual object. Therefore, values ​​of reference types are accessed by reference. The reference here can be roughly understood as an address stored in the variable object, which is associated with the actual value of the heap memory.

In order to better understand variable objects and heap memory, we can understand them with the following examples and diagrams.

var a1 = 0; // variable object var a2 = 'this is string'; // variable object var a3 = null; // variable object var b = { m: 20 }; // variable b exists in the variable object, {m: 20} exists as an object in the heap memory var c = [1, 2, 3]; // variable c exists in the variable object, [1, 2, 3] exists as an object in the heap memory 

Illustration of the above example

Therefore, when we want to access the reference data type in the heap memory, we actually first obtain the address reference (or address pointer) of the object from the variable object, and then obtain the data we need from the heap memory.

After understanding the memory space of JS, we can use the characteristics of the memory space to verify some characteristics of the reference type.

In front-end interviews, we often encounter a similar question.

// demo01.js
var a = 20;
var b = a;
b = 30;

// What is the value of a at this time?
// demo02.js
var m = { a: 10, b: 20 }
var n = m;
na = 15;

// What is the value of ma at this time

When data in a variable object is copied, the system automatically assigns a new value to the new variable. After var b = a is executed, although the values ​​of a and b are both equal to 20, they are actually independent of each other and do not affect each other. See the picture for details. So after we modify the value of b, the value of a will not change.

demo01 diagram

In demo02, we perform a copy reference type operation by using var n = m. Copying a reference type will also automatically assign a new value to the new variable and save it in the variable object, but the difference is that this new value is just an address pointer of the reference type. When the address pointers are the same, although they are independent of each other, the specific object accessed in the variable object is actually the same. As shown in the picture.

So when I change n, m also changes. This is the nature of reference types.

demo02 diagram

If you understand it from the perspective of memory, it will feel a lot easier. In addition, we can also use this as a basis to understand important concepts such as JavaScript's execution context, scope chain, closure, prototype chain, etc. step by step. I will slowly summarize the rest in future articles, so stay tuned.

Memory space management

Because JavaScript has an automatic garbage collection mechanism, we don’t have to worry about memory usage during development. Memory allocation and recycling are completely automatically managed. However, based on my own development experience, understanding the memory mechanism helps me to clearly understand what happened during the execution of the code I wrote, so that I can write code with better performance. Therefore, caring about memory is a very important thing.

JavaScript memory life cycle

1. Allocate the memory you need

2. Use the allocated memory (read, write)

3. Release or return it when no longer needed

To make it easier to understand, we use a simple example to explain this cycle.

var a = 20; // Allocate space in memory for a numeric variable alert(a + 100); // Use memory var a = null; // Release memory space after use

The first and second steps are easy to understand. JavaScript completes memory allocation when defining variables. The third step, releasing memory space, is a point we need to focus on understanding.

JavaScript has an automatic garbage collection mechanism, so what is the principle of this automatic garbage collection mechanism? In fact, it is very simple, just find out the values ​​that are no longer used and then release the memory they occupy. The garbage collector performs a release operation at regular intervals.

In JavaScript, the most commonly used method is to use the mark-and-sweep algorithm to find which objects are no longer in use. Therefore, a = null actually just releases the reference, causing the value originally corresponding to a to lose the reference and leave the execution environment. This value will be found and released the next time the garbage collector executes an operation. And dereferencing at the right time is an important way to get better performance for your page.

In the local scope, when the function is executed, the local variables are no longer necessary, so the garbage collector can easily make a judgment and recycle them. However, it is difficult to determine when global variables need to automatically release memory space. Therefore, in our development, we need to avoid using global variables as much as possible to ensure performance issues. To learn more about the garbage collection mechanism, it is recommended to read Section 4.3 of "Advanced JavaScript Programming"

The above is a detailed explanation of JS memory space. For more information about JS memory space, please pay attention to other related articles on 123WORDPRESS.COM!