Detailed explanation of JavaScript operation mechanism and a brief discussion on Event Loop

1. Why is JavaScript single-threaded?

A major feature of the JavaScript language is single-threaded, that is, only one thing can be done at the same time. So, why can't JavaScript have multiple threads? This can improve efficiency.

JavaScript的單線程, which is related to its purpose. As a browser scripting language, JavaScript 's main purpose is to interact with users and manipulate DOM . This determines that it can only be single-threaded, otherwise it will bring very complicated synchronization problems. For example, suppose JavaScript has two threads at the same time, one thread adds content to a DOM node, and the other thread deletes the node. Which thread should the browser follow?

Therefore, in order to avoid complexity, JavaScript has been single-threaded since its birth. This has become a core feature of the language and will not change in the future.

In order to utilize the computing power of multi-core CPU , HTML5 proposes the Web Worker standard, which allows JavaScript scripts to create multiple threads. However, the child threads are completely controlled by the main thread and are not allowed to operate DOM . Therefore, this new standard does not change the single-threaded nature of JavaScript.

2. Task Queue

Single-threaded means that all tasks need to be queued, and the next task will be executed only after the previous task is completed. If the previous task takes a long time, the next task will have to wait.

If the queue is due to the large amount of calculation and CPU is too busy, it's fine, but most of the time CPU is idle because the IO devices (input and output devices) are very slow (such as Ajax operations reading data from the network), and it has to wait for the results to come out before executing further.

The designers of the JavaScript language realized that at this time the main thread could completely ignore the IO device, suspend the waiting tasks, and run the tasks that are queued later first. Wait until the IO device returns the result, then go back and continue executing the suspended task.

Therefore, all tasks can be divided into two types, one is synchronous task ( synchronous ) and the other is asynchronous task (asynchronous). A synchronous task refers to a task queued for execution on the main thread. The next task can only be executed after the previous task is completed. An asynchronous task refers to a task that does not enter the main thread but enters the " task queue ". Only when the "task queue" notifies the main thread that an asynchronous task can be executed, will the task enter the main thread for execution.

Specifically, the operating mechanism of asynchronous execution is as follows. (The same is true for synchronous execution, since it can be viewed as asynchronous execution without the asynchronous tasks.)

(1) All synchronous tasks are executed on the main thread, forming an execution context stack stack.
(2) In addition to the main thread, there is also a " task queue ". As long as the asynchronous task has a running result, an event is placed in the "task queue".
(3) Once all synchronous tasks in the "execution stack" are executed, the system will read the "task queue" to see what events are in it. Those corresponding asynchronous tasks then end the waiting state, enter the execution stack, and start execution.
(4) The main thread continuously repeats step 3 above.

The figure below is a schematic diagram of the main thread and task queue.

As long as the main thread is empty, it will read the "task queue", which is the operating mechanism of JavaScript . This process will repeat itself.

3. Events and callback functions

The "task queue" is an event queue (it can also be understood as a message queue). When an IO device completes a task, it adds an event to the "task queue", indicating that the related asynchronous task can enter the "execution stack". The main thread reads the "task queue", that is, reads what events are in it.

The events in the "task queue" include not only events from IO devices, but also some events generated by users (such as mouse clicks, page scrolling, etc.). As long as the callback function is specified, these events will enter the "task queue" when they occur, waiting to be read by the main thread.

The so-called " callback function" is the code that will be suspended by the main thread. Asynchronous tasks must specify a callback function. When the main thread starts executing the asynchronous task, it executes the corresponding callback function.

The "task queue" is a first-in-first-out data structure. Events at the front are read by the main thread first. The reading process of the main thread is basically automatic. As long as the execution stack is cleared, the first event on the "task queue" will automatically enter the main thread. However, due to the "timer" function mentioned later, the main thread must first check the execution time. Certain events can only return to the main thread when the specified time has arrived.

4. Event Loop

The main thread reads events from the "task queue", and this process is continuous, so this entire operating mechanism is also called Event Loop.

To better understand Event Loop , please see the following figure

In the above figure, when the main thread runs, a heap and a stack are generated. The code in the stack calls various external APIs, which add various events ( click , load , done ) to the "task queue". As long as the code in the stack is executed, the main thread will read the "task queue" and execute the callback functions corresponding to those events in turn.

The code in the execution stack (synchronous tasks) is always executed before reading the "task queue" (asynchronous tasks). Please see the following example.

    var req = new XMLHttpRequest();
    req.open('GET', url);    
    req.onload = function (){};    
    req.onerror = function (){};    
    req.send();

The req.send method in the above code is an Ajax operation that sends data to the server. It is an asynchronous task, which means that the system will read the "task queue" only after all the codes in the current script are executed. Therefore, it is equivalent to the following.

    var req = new XMLHttpRequest();
    req.open('GET', url);
    req.send();
    req.onload = function (){};    
    req.onerror = function (){};   

That is to say, it doesn't matter whether the part that specifies the callback function ( onload and onerror ) is before or after the send() method, because they are part of the execution stack, and the system always executes them before reading the "task queue".

5. Timer

In addition to placing events for asynchronous tasks, the "task queue" can also place timed events, that is, specifying how much time it will take for certain codes to be executed. This is called a "timer" function, which is code that is executed at a fixed time.

The timer function is mainly completed by the two functions setTimeout() and setInterval() . Their internal operating mechanisms are exactly the same. The difference is that the code specified by the former is executed once, while the code specified by the latter is executed repeatedly. The following mainly discusses setTimeout()。

setTimeout() accepts two parameters, the first is the callback function, and the second is the number of milliseconds to postpone execution.

console.log(1);
setTimeout(function(){console.log(2);},1000);
console.log(3);

The execution results of the above code are 1, 3, 2, because setTimeout() postpones the execution of the second line to 1000 milliseconds later.

If the second parameter of setTimeout() is set to 0, it means that after the current code is executed (the execution stack is cleared), the specified callback function will be executed immediately (with an interval of 0 milliseconds).

setTimeout(function(){console.log(1);}, 0);
console.log(2);

The execution result of the above code is always 2, 1, because the system will execute the callback function in the "task queue" only after the second line is executed.

In short, the meaning of setTimeout(fn,0) is to specify that a task should be executed at the earliest available idle time of the main thread, that is, as early as possible. It adds an event to the end of the "task queue", so it will not be executed until the synchronization task and the existing events in the "task queue" are processed.

HTML5 standard stipulates that the minimum value (shortest interval) of the second parameter of setTimeout() must not be less than 4 milliseconds. If it is lower than this value, it will automatically increase. Prior to this, older versions of browsers set the minimum interval to 10 milliseconds. In addition, DOM changes (especially those involving page re-rendering) are usually not executed immediately, but every 16 milliseconds. At this time, requestAnimationFrame() is better than setTimeout()。

It should be noted that setTimeout() only inserts the event into the "task queue". The main thread will not execute the callback function it specifies until the current code (execution stack) is executed. If the current code takes a long time, you may have to wait for a long time, so there is no way to guarantee that the callback function will be executed at the time specified by setTimeout().

6. Node.js Event Loop

Node.js also has a single-threaded Event Loop , but its operating mechanism is different from that of the browser environment.

Please see the diagram below

According to the above figure, the operating mechanism of Node.js is as follows.

(1) The V8 engine parses JavaScript scripts.

(2) After parsing, the code calls the Node API.

(3) The libuv library is responsible for the execution of Node API . It assigns different tasks to different threads to form an Event Loop , and returns the execution results of the tasks to the V8 engine in an asynchronous manner.

(4) The V8 engine then returns the result to the user.

In addition to setTimeout and setInterval methods, Node.js also provides two other methods related to the "task queue": process.nextTick and etImmediate . They can help us deepen our understanding of "task queues".

process.nextTick method can trigger the callback function at the end of the current "execution stack" ---- before the next Event Loop (the main thread reads the "task queue"). That is, the task it specifies always happens before all asynchronous tasks. The setImmediate method adds an event to the end of the current "task queue", that is, the task it specifies is always executed at the next Event Loop , which is very similar to setTimeout(fn, 0) . See the example below ( via StackOverflow ).

process.nextTick(function A() {
  console.log(1);
  process.nextTick(function B(){console.log(2);});
});

setTimeout(function timeout() {
  console.log('TIMEOUT FIRED');
}, 0)
// 1
// 2
//TIMEOUT FIRED

In the above code, since the callback function specified by process.nextTick method is always triggered at the end of the current "execution stack", not only function A is executed before the callback function timeout specified by setTimeout , but function B is also executed before timeout . This means that if there are multiple process.nextTick statements (regardless of whether they are nested or not), all will be executed on the current "execution stack".

Now, let’s look at setImmediate

setImmediate(function A() {
  console.log(1);
  setImmediate(function B(){console.log(2);});
});

setTimeout(function timeout() {
  console.log('TIMEOUT FIRED');
}, 0);

In the above code, setImmediate and setTimeout(fn,0) each add a callback function A and timeout , both of which are triggered in the next Event Loop . So, which callback function executes first? The answer is uncertain. The running result may be 1--TIMEOUT FIRED--2 or TIMEOUT FIRED--1--2。

What is confusing is that Node.js documentation states that the callback function specified by setImmediate is always placed before setTimeout . In practice, this only happens with recursive calls.

setImmediate(function (){
  setImmediate(function A() {
    console.log(1);
    setImmediate(function B(){console.log(2);});
  });

  setTimeout(function timeout() {
    console.log('TIMEOUT FIRED');
  }, 0);
});
// 1
//TIMEOUT FIRED
// 2

In the above code, setImmediate and setTimeout are encapsulated in one setImmediate , and its running result is always 1--TIMEOUT FIRED--2. At this time, function A must be triggered before timeout. As for the fact that function 2 is placed after TIMEOUT FIRED (i.e. function B is triggered after timeout ), it is because setImmediate always registers the event to the next round Event Loop , so function A and timeout are executed in the same round of Loop, while function B is executed in the next round of Loop.

From this we can see an important difference between process.nextTick and setImmediate : multiple process.nextTick statements are always executed once in the current "execution stack", while multiple setImmediate may require multiple loops to execute. In fact, this is exactly why Node.js version 10.0 added setImmediate method. Otherwise, the recursive call process.nextTick like the following will never end, and the main thread will not read the "event queue" at all!

process.nextTick(function foo() {
  process.nextTick(foo);
});

In fact, if you write a recursive process.nextTick，Node.js will throw a warning and ask you to change it setImmediate .

In addition, since the callback function specified by process.nextTick is triggered in the current "event loop", and setImmediate is triggered in the next "event loop", it is obvious that the former always occurs earlier than the latter and has higher execution efficiency (because there is no need to check the "task queue").

This concludes this article on the detailed explanation of JavaScript operating mechanism and a brief discussion of Event Loop. For more information about JavaScript operating mechanism and Event Loop , please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!