A detailed introduction to JavaScript execution mechanism

Preface:

Whether it is work or interview, we may often encounter scenarios where we need to know the execution order of the code, so I plan to spend some time to thoroughly understand the execution mechanism of JavaScript.

To understand the JavaScript execution mechanism, you need to know the following: (Take the browser environment as an example, which is different from the Node environment)

1. The concept of process and thread

• Browser Principle
• Event loop (Event-Loop), task queue (synchronous tasks, asynchronous tasks, microtasks, macrotasks)
• Processes and threads
  

We all know that the core of the computer is the CPU, which undertakes all computing tasks; the operating system is the manager of the computer, which is responsible for task scheduling, resource allocation and management, and controls the entire computer hardware; the application is a program with certain functions, and the program runs on the operating system.

process:

A process is the dynamic execution process of a program with independent functions on a data set. It is an independent unit for resource allocation and scheduling by the operating system. It is the carrier for application programs to run. A process is the smallest unit that can own resources and run independently, and it is also the smallest unit of program execution.

Characteristics of a process:

• Dynamicity: A process is an execution process of a program. It is temporary, has a life cycle, and is dynamically generated and destroyed.
• Concurrency: Any process can be executed concurrently with other processes;
• Independence: A process is an independent unit for resource allocation and scheduling in the system;
• Structural: A process consists of three parts: program, data, and process control block.
  

Threads:

A thread is a single sequential control flow in program execution, the smallest unit of program execution flow, and the basic unit of processor scheduling and dispatching. A process can have one or more threads, and each thread shares the program's memory space (that is, the memory space of the process). A standard thread consists of a thread ID, the current instruction pointer (PC), registers, and a stack. A process consists of memory space (code, data, process space, open files) and one or more threads.

The difference between a process and a thread:

• A thread is the smallest unit of program execution, while a process is the smallest unit of resource allocation by the operating system.
• A process consists of one or more threads, which are different execution routes of the code in a process;
• Processes are independent of each other, but threads under the same process share the program's memory space (including code segments, data sets, heaps, etc.) and some process-level resources (such as open files and signals). Processes are not visible to each other.
• Scheduling and switching: Thread context switching is much faster than process context switching.
  

Why is JS single-threaded?

JavaScript has been used as a scripting language for browsers since its inception, mainly used to handle user interactions and operate DOM. This determines that it can only be single-threaded, otherwise it will bring very complex synchronization problems.

For example: If JS is multi-threaded, one thread wants to modify a DOM element, and another thread wants to delete the DOM element. At this time, the browser does not know who to listen to. So in order to avoid complexity, JavaScript was designed to be single-threaded from the beginning.

In order to utilize the computing power of multi-core CPUs, 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 the DOM. Therefore, this new standard does not change the nature of JavaScript being single-threaded.

2. Browser Principle

As a front-end engineer, you must be familiar with browsers, and browsers are multi-process.

Browser components:

• User interface : including address bar, forward/backward/refresh/bookmarks, etc.
• Browser engine : transfers instructions between the user interface and the rendering engine
• Rendering engine : used to draw the requested content
• Network : used to complete network calls, such as http requests, it has a platform-independent interface and can work on different platforms
• JavaScript interpreter : used to parse and execute JavaScript code
• User interface backend : used to draw basic widgets, such as combo boxes and windows, and uses the operating system's user interface at the bottom
• Data storage : belongs to the persistence layer. The browser saves various data similar to cookie in the hard disk. HTML5 defines web database technology, which is a lightweight and complete client storage technology.
  

⚠️Note : Unlike most browsers, Chrome has a separate rendering engine instance per tab. Each tab is a separate process

What processes does a browser consist of?

Browser process:

• The main process of the browser (responsible for coordination and control), there is only one
• Responsible for browser interface display and interaction with users. Such as forward, backward, etc.
• Responsible for the management of various pages, creating and destroying other processes
• Draw Bitmap in memory obtained by the Renderer process onto the user interface
• Management of network resources, downloading, etc.
  

Third-party plugin process:

• Responsible for managing third-party plug-ins
  

GPU Process:

• Responsible for 3D drawing and hardware acceleration (maximum one)
  

Rendering process :

• Responsible for page document parsing, execution and rendering
  

What threads does the rendering process contain?

GUI rendering thread:

• Mainly responsible for parsing HTML, CSS, building DOM tree, layout, drawing, etc.
• This thread is mutually exclusive with the JavaScript engine thread. When JavaScript engine thread is executed, the GUI rendering thread will be suspended. When the task queue is idle, the main thread will execute the GUI rendering.
  

JavaScript engine thread:

• Mainly responsible for processing JavaScript scripts and executing codes (such as V8 engine)
• The browser can only have one JS engine thread running the JS program at the same time, that is, JS is single-threaded.
• The JS engine thread and the GUI rendering thread are mutually exclusive, so the JS engine will block page rendering
  

Timing trigger thread:

• Responsible for executing timer functions ( setTimeout，setInterval )
• The browser timing counter is not counted by the JS engine (because JS is single-threaded, if it is in a blocked state, it will affect the accuracy of the counter)
• A separate thread is used to time and trigger the timing (after the timing is completed, it is added to the event queue of the event trigger thread and waits for the JS engine to be idle before execution). This thread is the timing trigger thread, also called the timer thread.
• W3C stipulates in the HTML standard that the time interval less than 4ms in setTimeout is counted as 4ms.
  

Event triggering thread:

• Responsible for handing over the prepared events to the JS engine thread for execution
• When an event is triggered, the thread will add the corresponding event to the end of the queue to be processed, waiting for the JS engine to process it.
  

Asynchronous request thread:

• After the XMLHttpRequest connection, the browser will open a thread
• When detecting a request status change, if there is a corresponding callback function, the asynchronous request thread will generate a status change event and put the corresponding callback function into the queue to wait for the JS engine to execute.
  

3. Synchronous vs. Asynchronous

Since JavaScript is single-threaded, its tasks cannot be just synchronous tasks. If tasks that take a long time are also executed as synchronous tasks, the page will be blocked.

So JavaScript tasks are generally divided into two categories:

Synchronous tasks:

Synchronous tasks refer to tasks queued for execution on the main thread. The next task can only be executed after the previous task is completed.

Asynchronous tasks:

An asynchronous task refers to a task that does not enter the main thread but enters the "task queue" (Event queue). Only when the "task queue" notifies the main thread that an asynchronous task can be executed, the task will enter the main thread for execution.

Common asynchronous tasks: timers, ajax, event binding, callback functions, promise , async await , etc.

• Synchronous and asynchronous tasks enter different execution "places" respectively. Synchronous tasks enter the main thread, while asynchronous tasks enter the Event Table and register functions.
• When the things specified in the Event Table are completed, this function will be moved into the Event Queue.
• When the task in the main thread is completed and is empty, it will go to Event Queue to read the corresponding function and enter the main thread for execution.
• The above process will be repeated continuously, which is often called Event Loop.
• We can't help but ask, how do we know that the main thread execution stack is empty? The js engine has a monitoring process that continuously checks whether the main thread execution stack is empty. Once it is empty, it goes to Event Queue to check whether there are any functions waiting to be called.
  

Macrotasks and microtasks:

In addition to the broad synchronous and asynchronous tasks, JavaScript also has more sophisticated task definitions:

• Macro-task: including global code, setTimeout, setInterval
• Micro-task: new Promise().then(callback) process.nextTick()

Different types of tasks will enter different task queues:

The order of the event loop determines the execution order of the js code. After entering the overall code (macro task), the first loop begins. Then execute all microtasks. Then start from the macro task again, find one of the task queues to complete, and then execute all the micro tasks.

4. Execution stack and task queue

Execution stack:

JavaScript code is executed in an execution context. There are three execution contexts in JavaScript:

• Global Execution Context
• Function execution context, a function execution context is created when a JS function is called
• eval execution context, the context generated by the eval function (less commonly used)
  

Generally speaking, our JS code has more than one context, so what is the execution order of these contexts?

We all know that the stack is a last-in-first-out data structure. The execution stack in our JavaScript is such a stack structure. When the JS engine executes code, a global context is generated and pushed into the execution stack. Whenever a function call is encountered, a function execution context is generated and pushed into the execution stack. The engine starts executing the function from the top of the stack and pops the execution context after execution.

function add(){
  console.log(1)
  foo()
  console.log(3)
}

function foo(){
  console.log(2)
}
add()

Let's take a look at the execution stack of the above code:

Task Queue:

Earlier we mentioned that all tasks in JavaScript are divided into synchronous tasks and asynchronous tasks. Synchronous tasks, as the name suggests, are tasks that are executed immediately. They generally enter the main thread directly for execution. Our asynchronous tasks enter the task queue and wait for the tasks in the main thread to be completed before execution.

The task queue is a queue of events, indicating that related asynchronous tasks can enter the execution stack. The main thread reads the task queue to read what events are in it.

A queue is a first-in-first-out data structure.

As mentioned above, asynchronous tasks can be divided into macrotasks and microtasks, so task queues can also be divided into macrotask queues and microtask queues.

• Macrotask Queue : performs relatively large tasks, including setTimeout , setInterval , user interaction, UI rendering, etc.
• Microtask Queue : performs smaller tasks, commonly used are Promise and Process.nextTick ;

5. Event-Loop

• Synchronous tasks are directly put into the main thread for execution, and asynchronous tasks (click events, timers, ajax, etc.) are executed in the background, waiting for I/O events to complete or behavioral events to be triggered.
• The system executes asynchronous tasks in the background. If an asynchronous task event (or behavior event) is triggered, the task is added to the task queue, and each task will correspond to a callback function for processing.
• Here, asynchronous tasks are divided into macrotasks and microtasks. Macrotasks enter the macrotask queue, and microtasks enter the microtask queue.
• The tasks in the execution task queue are completed in the execution stack. When all the tasks in the main thread are executed, the microtask queue is read. If there are microtasks, they will all be executed, and then the macrotask queue is read.
• The above process will be repeated continuously, which is what we often call Event-Loop ).

Example verification:

Let's look at a question to verify it

(async () => {
    console.log(1) 
  
    setTimeout(() => {
    console.log('setTimeout1')
    }, 0);
  
    function foo () {
        return new Promise((res,rej) => {
            console.log(2)
            res(3)
        })
    }
  
    new Promise((resolve,reject)=>{
    console.log(4)
    resolve() 
    console.log(5)
    }).then(()=> {
    console.log('6')
    })
  
    const res = await foo();
    console.log(res);
    console.log('7')
  
    setTimeout(_ => console.log('setTimeout2'))
})()

The printing order is: 1,4,5,2,6,3,7,setTimeout1,setTimeout2

analyze:

• The code is executed from top to bottom. First, it encounters console.log(1) , which prints 1 directly. Then it encounters the timer, which belongs to the macro task, and puts it into the macro task queue.
• When we encounter promise again, since new Promise is a synchronous task, we print 4 directly. When we encounter resolve, which is the subsequent then function, we put it into the microtask queue and print 5.
• Then execute await foo. There is a promise in the foo function. new promise belongs to synchronous tasks, so 2 will be printed directly. What await returns is a promise callback. The tasks after await are put into the microtask queue.
• Finally, a timer is encountered and put into the macro task queue
• After the execution stack task is executed, go to the microtask queue to get the microtask execution. First execute the first microtask, print 6, then execute the second microtask, print 3, 7
• After the microtask is executed, go to the macrotask queue to get the macrotask execution and print setTimeout1 and setTimeout2
  

6. Timer

Asynchronous tasks in JavaScript 's task queue also include timer events, which specify how long it will take for certain codes to be executed. The timer function is mainly completed by two functions, setTimeout() and nterval() . Their internal execution mechanisms are exactly the same. The main difference is that setTimeout is a one-time execution process, while setInterval is a repeated execution process.

The setTimeout function accepts two parameters, the first is the callback function to be executed, and the second is the time (ms) to postpone execution.

If we set the delay time to 0, will it be executed immediately?

setTimeout(()=>{
    console.log(1)
},0)

console.log(2)

But this is not the case. The print result above is that 2 is printed first, and then 1. Do you feel confused?

It is very clear to understand it using the rules of the event loop above. The global code is executed, and when the timer setTimeout is encountered, it is put into the macro task queue, and then the synchronization code is executed downwards, printing 2. After the stack task is executed, it goes to the micro task queue. If there is no micro task, look at the macro task queue again. There is a macro task, and print 1 is executed.

The meaning of setTimeout(fn,0) is to specify that a task is executed at the earliest available idle time of the main thread, that is, to execute it 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.

The 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() .

This is the end of this article about the detailed introduction of JavaScript execution mechanism. For more relevant content about JavaScript execution mechanism, 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!