The order of event execution in the node event loop

Event Loop

In the browser environment, our js has its own event loop, and there is also a similar event loop in the node environment.

Browser environment event loop

First, let's review the event loop in the browser:

In summary:

First, the synchronous code of the main thread will be run. Each line of synchronous code will be pushed into the execution stack, and each line of asynchronous code will be pushed into the asynchronous API (such as timer thread, ajax thread, etc.). When there is no code to be executed in the execution stack, that is, our current main thread has no synchronous code, the task queue will take a microtask from our asynchronous task microtask queue and put it into our task queue for execution , and then put its callback function into the execution stack again for execution . When the microtask queue is empty , the asynchronous task will be taken from the macrotask and added to the task queue , and then pushed into the execution stack , execute the callback function , and then continue to search for synchronous and asynchronous tasks in the macrotask. One cycle completes an event loop (event polling)

Example in a browser environment:

example:

        console.log("1");
        setTimeout(() => {
            console.log("setTimeout");
        }, 1);
        new Promise((res, rej) => {
            console.log("Promise");
            res('PromiseRes')
        }).then(val => {
            console.log(val);
        })
        console.log("2");

analyze:
First, the execution stack finds the first line of synchronous code and throws it directly into the execution stack for execution, prints 1, followed by the timer setTimeout, which is an asynchronous task. The code is placed in the asynchronous queue waiting for execution, and then the code in the promise is executed. We must be clear that promise is executed synchronously and its callback is executed asynchronously. All print Promise and put res('PromiseRes') in the asynchronous queue waiting for execution. At this time, the synchronous code is encountered again, print 2, and all the synchronous codes of the current main thread have been executed. There is no synchronous code to be executed in the execution stack. At this time, webApi will go to the first one in the microtask queue from the asynchronous queue, add it to the event queue for execution, push the returned callback function into the execution stack for execution, print PromiseRes, and then the microtask is executed. There is no microtask anymore. Now you need to take the macrotask timer from the macrotask queue, add it to the task queue, push the callback function into the execution stack for execution, and print setTimeout.

Node environment event loop

In node, the event loop is mainly divided into six stages :

External data input –> Polling phase –> Checking phase –> Shutdown event callback phase –> Timer phase –> I/O callback phase –> Idle phase –> Polling phase… Start loop

Six stages

The picture comes from the Internet

• Timers phase: used to execute the callback of timer (setTimeout, setInterval);
• I/O callbacks phase: Processes a few I/O callbacks that were not executed in the previous cycle
• Idle, prepare phase: only used internally by the node, we don’t need it;
• Poll phase: Get new I/O time. Under appropriate conditions, the node will block here.
• Check phase: execute the callback of setImmediate();
• Close callbacks phase: execute the socket close time callback

Main stages :
timer:
The timers phase executes setTimeout and setInterval callbacks and is controlled by the poll phase.
Similarly, the time specified by the timer in the node is not the exact time, it can only be executed as soon as possible.
poll:
During the poll phase, the system does two things:
1. Return to the timer stage to execute the callback
2. Execute I/O callback and if no timer is set when entering this stage, the following two things will happen

If the poll queue is not empty, it will traverse the callback queue and execute synchronously until the queue is empty or the system limit is reached. If the poll queue is empty, two things will happen
1. If there is a setImmediate callback that needs to be executed, the poll phase will stop and enter the check phase to execute the callback
2. If there is no setImmediate callback to be executed, it will wait for the callback to be added to the queue and execute the callback immediately. There will also be a timeout setting to prevent waiting. Of course, if a timer is set and the poll queue is empty, it will determine whether the timer has timed out. If so, it will return to the timer stage to execute the callback.

Check stage
The callback of setImmediate() will be added to the check queue. From the stage diagram of the event loop, we can know that the execution order of the check stage is after the poll stage. When entering the check stage, the poll will check if there is any, and then go to the check stage. If not, it will go directly to the timer stage.

(1) setTimeout and setImmediate

The two are very similar, the main difference is the timing of the call.

setImmediate is designed to be executed when the poll phase is completed, that is, the check phase, and it will only be executed in the check phase;
setTimeout is designed to be executed when the poll phase is idle and the set time is reached, but it is executed in the timer phase, which means that the current thread has no other executable synchronization tasks, and the timer will be executed in the timer phase.

The timing of these two executions can be either before or after:
Example 1:

// //Macro task in asynchronous task setTimeout(() => {
    console.log('===setTimeout===');
},0);
setImmediate(() => {
    console.log('===setImmediate===')
})

The results of repeated executions will be different, and there is a sense of randomness. The reason for this is mainly related to the implementation code of setTimeout. When we do not pass the time parameter or set it to 0, nodejs will take the value of 1, that is, 1ms (the value on the browser side may be larger, and different browsers are also different). Therefore, if the computer CPU is strong enough to execute the timers phase within 1ms, the callback will not be executed because the time delay does not meet the requirements, so it can only wait until the second round to execute, so setInterval will be executed first.
The above random phenomenon may be caused by slight differences in the time taken by the CPU to execute the same task multiple times, and fluctuating within 1ms.
Generally, when setTimeout is 0, it will be executed before setImmediate

Example 2:
When the value we pass in is greater than the callback time of the timer execution, it will directly cause the timer to execute in the next event loop

setTimeout(() => {
    console.log('===setTimeout===');
},10);
setImmediate(() => {
    console.log('===setImmediate===')
})

Example 3:
When we put the above code into an i/o, it will always check first and then the timer:

const fs = require('fs');

fs.readFile("./any.js", (data) => {
    setTimeout(() => {
        console.log('===setTimeout===');
    },10);
    setImmediate(() => {
        console.log('===setImmediate===')
    })
});

In the first round of the loop, the file is read. In the callback, it will enter the check phase and execute setImmediate, and then the timer will be executed in the timer phase.
If setimmediate and settimeout are called in the same I/O loop, setImmediate will always be called first.

(2) process.nextTick

This function is actually independent of the Event Loop. It has its own queue. When each stage is completed, if there is a nextTick queue, all callback functions in the queue will be cleared and executed first before other microtasks.

Example 1:

setTimeout(() => {
 console.log('timer1')
 Promise.resolve().then(function() {
   console.log('promise1')
 })
}, 0)
process.nextTick(() => {
 console.log('nextTick')
 process.nextTick(() => {
   console.log('nextTick')
   process.nextTick(() => {
     console.log('nextTick')
     process.nextTick(() => {
       console.log('nextTick')
     })
   })
 })
})
// nextTick=>nextTick=>nextTick=>nextTick=>timer1=>promise1

Example 2:

const fs = require('fs');

fs.readFile("./any.js", (data) => {
    process.nextTick(()=>console.log('process===2'))
    setTimeout(() => {
        console.log('===setTimeout===');
    },10);
    setImmediate(() => {
        console.log('===setImmediate===')
    })
});
process.nextTick(()=>console.log('process===1'))

Practice Examples

async function async1() {
    console.log('2')
    //Will wait for await to finish but will not execute further because the following microtask await async2() is entered
    console.log('9')
  }
   
   function async2() {
    console.log('3')
  }
   
  console.log('1')
   
  setTimeout(function () {
    console.log('11')
  }, 0)
   
  setTimeout(function () {
    console.log('13')
  }, 300)
   
  setImmediate(() => console.log('12'));
   
  process.nextTick(() => console.log('7'));
   
  async1();
   
  process.nextTick(() => console.log('8'));
   
  new Promise(function (resolve) {
    console.log('4')
    resolve();
    console.log('5')
  }).then(function () {
    console.log('10')
  })
   
  console.log('6')

analyze:
The sequence above is the order of the serial numbers;
First print 1:
There are two function declarations in front, all of which directly print 1, this line of synchronous code;
Print 2:
After printing 1, all the codes are asynchronous. They are added to the asynchronous task queue and directly called to the async1 function. 2 is printed in this function.
Print 3:
The async1 function is an async await function, so it is also a disguised synchronous operation waiting for the async2 function to execute. After async2 is executed, 9 will not be printed directly because await accepts a promise's then operation, so the callback operation that belongs to a promise is a microtask and is added to the microtask queue.
Print 4:
process.nextTick is a microtask, so it will continue to execute the promise and print 4;
Print 5:
The callback of resolve() will not be executed immediately and belongs to the microtask. It will be added to the microtask queue, so 5 is printed;
Print 6:
The last main thread synchronization code prints 6;
Print 7 and 8:
process.nextTick has a higher priority than other timers, so the callback function will be executed directly to print 7 and 8;
Print 9, 10:
At this time, the microtasks in the microtask queue need to be executed. Currently, there are two 9 and 10. In order, 9 is printed first and then 10.
Print 11, 12:
setTimeout is 0 seconds, which is earlier than setImmediate. In order of execution, 11 is printed first and 12 is printed later.
Print 13:
The function with setTimeout of 300ms prints 13;

example:

async function async1() {
    console.log('2')
    //Will wait for await to finish but will not execute further because the following microtask await async2() is entered
    console.log('9')
  }
   
   function async2() {
    console.log('3')
  }
   
  console.log('1')
   
  setTimeout(function () {
    console.log('11')
    setTimeout(() => {
        console.log('11-1');
    },100);
    setImmediate(() => {
        console.log('11-2')
    })
  }, 0)
   
  setTimeout(function () {
    console.log('13')
    setTimeout(() => {
        console.log('15');
    },10);
    setImmediate(() => {
        console.log('14')
    })
  }, 300)
  setImmediate(() => console.log('12'));
  process.nextTick(() => console.log('7'));
  async1();
   
  process.nextTick(() => console.log('8'));
   
  new Promise(function (resolve) {
    console.log('4')
    resolve();
    console.log('5')
  }).then(function () {
    console.log('10')
  })
   
  console.log('6')

Summarize:

This is the end of this article about the order of event execution in the node event loop. For more information about the order of node event execution, 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!

Reference: https://www.cnblogs.com/everlose/p/12846375.html