Comprehensive understanding of Node event loop

Node Event Loop

The underlying language of Node is libuv , which is a C++ language. It is used to operate the underlying operating system and encapsulates the operating system interface. Node's event loop is also written in libuv , so the Node life cycle is different from that of the browser.

Because Node deals with the operating system, the event loop is relatively complex and has some unique APIs of its own.
The event loop has some subtle differences in different operating systems. This will involve knowledge of operating systems, which will not be discussed for now. This time we will only introduce the operation process of Node in the JS main thread. Other Node threads will not be expanded for the time being.

Event loop diagram

As promised, there will be a picture, and I won’t keep you in suspense. Once you understand the picture below, you will have learned the event loop.

Event loop diagram

Event loop diagram - structure

In order to give everyone a general idea, here is a directory structure diagram :

Table of contents

Next, let’s talk about it in detail.

Main Thread

Main Thread

In the above picture, the meanings of several color blocks are:

• main : Start the entry file and run the main function
• event loop : Check whether to enter the event loop Check whether there are pending tasks in other threads Check whether other tasks are still in progress (such as timers, file reading operations, etc.) If the above situation occurs, enter the event loop and run other tasks
• The process of the event loop: follow the process from timers to close callbacks. Go to the event loop to see if it is finished. If not, go through another circle.
• over : all things are finished, ended

Event loop

Event loop

The gray circle in the figure is related to the operating system and is not the focus of this chapter's analysis. Pay special attention to the yellow and orange circles and the orange box in the middle.

We call each round of the event loop "a cycle", also called "a poll", or "a tick".

A cycle goes through six stages:

1. timers: timers (callback functions of setTimeout, setInterval, etc. are stored in them)
2. pending callback
3. idle prepare
4. poll: polling queue (callbacks other than timers and checks are stored here)
5. check: Check phase (callbacks using setImmediate will directly enter this queue )
6. close callbacks

This time we only focus on the three key points marked in red above.

How it works

• Each stage maintains an event queue. You can think of each circle as an event queue.
• This is different from browsers, which have at most two queues (macro queue and micro queue). But there are six queues in the node
• After arriving at a queue, check whether there is a task in the queue (that is, see if there is a callback function) that needs to be executed. If there are, they will be executed in sequence until all are executed and the queue is cleared.
• If there is no task, go to the next queue to check. Until all queues are checked, it is considered one poll.

Among them, timers , pending callback , idle prepare , etc. arrive at poll queue after execution.

How the timers queue works

Timers are not queues in the true sense, they store timers inside.
Every time it reaches this queue, it checks all timers in the timer thread, and multiple timers in the timer thread are sorted in chronological order.

Checking process: Calculate each timer in order, and calculate whether the time from the start of the timer to the current time meets the timer interval parameter setting (for example, 1000ms, calculate whether 1m has passed since the start of the timer). When a timer check passes, its callback function is executed.

How the poll queue works

• If there are callback functions in poll that need to be executed, the callbacks are executed in sequence until the queue is cleared.
• If there is no callback function in poll that needs to be executed, the queue is empty. It will wait here for callbacks to appear in other queues.
• If a callback occurs in other queues, the process goes from poll to over, ending this phase and entering the next phase.
• If there is no callback in other queues, it will continue to wait in the poll queue until any queue has a callback and then work. (This is the way a lazy idiot does things)

Example of event flow

setTimeout(() => {
  console.log('object');
}, 5000)
console.log('node');

The event flow of the above code

Enter the main thread and execute setTimeout(). The callback function is placed in the asynchronous queue timers as an asynchronous task and is not executed for the time being.

• Continue down and execute the console after the timer to print "node".
• Determine whether there is an event loop. Yes, go through the polling: from timers - pending callback - idle prepare...
• Go to the poll queue to stop the loop and wait.
• Since it has not been 5 seconds yet, there is no task in the timers queue, so it is stuck in the poll queue and polls other queues to check whether there are any tasks.
• After 5 seconds, the callback of setTimeout is inserted into timers. The routine polling checks that there is a task in the timers queue, so it goes down and reaches timers after checking and close callbacks. Clear the timers queue.
• Continue to poll and wait to ask whether the event loop is still needed. If not, it reaches over and ends.

To understand this problem, look at the following code and process analysis:

setTimeout(function t1() {
  console.log('setTimeout');
}, 5000)
console.log('node life cycle');

const http = require('http')

const server = http.createServer(function h1() {
  console.log('request callback');
});

server.listen(8080)

The code analysis is as follows:

• As usual, execute the main thread first, print the "node life cycle", introduce http and create the http service.
• Then the event loop checks whether there are asynchronous tasks and finds timer tasks and request tasks. So enter the event loop.

If there are no tasks in the six queues, they will wait in the poll queue. As shown below:

• After five seconds, there is a task in the timers, and the process is released from poll, passing through the check and close callbacks queues, and reaches the event loop.
• The event loop checks whether there are asynchronous tasks and finds timer tasks and request tasks. So enter the event loop again.
• When it reaches the timers queue and finds a callback function task, it executes the callbacks in sequence, clears the timers queue (of course there is only one callback after 5 seconds, so it can be executed directly), and prints out "setTimeout". As shown below

• After clearing the timers queue, polling continues down to the poll queue. Since the poll queue is now empty, it waits here.
• Later, assuming that a user request comes in, the h1 callback function is placed in the poll queue. Therefore, there are callback functions in poll that need to be executed, and the callbacks are executed in sequence until the poll queue is cleared.
• The poll queue is cleared. At this time, the poll queue is an empty queue and continues to wait.

• Since the node thread is always holding in the poll queue, if there is no task for a long time, it will automatically disconnect and wait (unconfident performance), and execute the polling process downward, and reach the event loop after the check and close callbacks.
• After reaching the event loop, check whether there is an asynchronous task and find that there is a request task. (At this time, the timer task has been executed, so it no longer exists), then continue to enter the event loop again.
• Arriving at the poll queue, holding again...
• If no task comes after a long wait, it will automatically disconnect to the even loop (add a little more about the loop situation with no task)
• Return to the poll queue again and suspend

Infinite loop...

Sorting out the event loop flow chart:

Note: The term "Is there a task" in the figure below means "Is there a task in this queue?"

Event loop process summary

Let's use a typical example to verify the process:

const startTime = new Date();

setTimeout(function f1() {
  console.log('setTimeout', new Date(), new Date() - startTime);
}, 200)

console.log('node life cycle', startTime);

const fs = require('fs')

fs.readFile('./poll.js', 'utf-8', function fsFunc(err, data) {
  const fsTime = new Date()
  console.log('fs', fsTime);
  while (new Date() - fsTime < 300) {
  }
  console.log('End of infinite loop', new Date());
});

Run three times in a row and print the following results:

Execution process analysis:

1. Execute the global context and print "node life cycle + time"
2. Ask if there is an event loop
3. Yes, enter the timers queue and check if there is any timer (the CPU processing speed is OK, and it has not reached 200ms at this time)
4. The polling enters poll, but the file has not been read completely (for example, it only took 20ms at this time), so the poll queue is empty and there is no task callback.
5. Waiting in the poll queue... Keep polling to see if there is a callback
6. After the file is read, the poll queue has the fsFunc callback function, which is executed and outputs "fs + time"
7. The while loop is stuck for 300 milliseconds.
8. When the infinite loop reaches 200ms, the f1 callback enters the timers queue. But at this time the poll queue is very busy, occupying the thread and will not execute further.
9. After 300ms, the poll queue is cleared and the output is "End of infinite loop + time"
10. The event loop quickly goes down
11. It is timers' turn again, and the f1 callback in the timers queue is executed. So I saw "setTimeout + time"
12. The timers queue is cleared and returns to the poll queue. There is no task, so wait for a while.

After waiting long enough, go back down to the event loop.

The event loop checks that there are no other asynchronous tasks, ends the thread, and the entire program exits.

Check Phase

Check phase (callbacks using setImmediate will go directly into this queue)

How the check queue actually works

The real queue contains a collection of callback functions to be executed. Similar to the form of [fn,fn].
Every time you reach the check queue, you can immediately execute the callback function in sequence [similar to [fn1,fn2].forEach((fn)=>fn())]

Therefore, setImmediate is not a timer concept.

If you go for an interview and it involves Node, you may encounter the following question: which is faster, setImmediate or setTimeout(0)?

setImmediate() vs. setTimeout(0)

• The callback of setImmediate is asynchronous, which is consistent with the callback nature of setTimeout.
• The setImmediate callback is in the check queue, and the setTimeout callback is in the timers queue (in conceptual terms, it is actually in the timer thread, but setTimeout makes a check call in the timers queue. See how timers work for details).
• After the setImmediate function is called, the callback function will be immediately pushed to the check queue and executed at the next event loop. After the setTimeout function is called, the timer thread adds a timer task. The next time the event loop is called, it will check in the timers phase to determine whether the timer task has arrived. If so, the callback function will be executed.

In summary, setImmediate operates faster than setTimeout(0) because setTimeout also needs to start a timer thread and increase the computational overhead.

The effects of the two are similar. But the execution order is uncertain

Observe the following code:

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

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

After running it repeatedly for many times, the execution effect is as follows:

Uncertain order

You can see that the order of the two console.log statements is not fixed when running multiple times.
This is because the minimum interval number of setTimeout is 1, although the code below is filled with 0. But the actual computer execution is calculated as 1ms. (Note that this is different from the browser timer. In the browser, the minimum interval of setInterval is 10ms, and if it is less than 10ms, it will be set to 10; when the device is powered on, the minimum interval is 16.6ms.)

In the above code, when the main thread is running, the setTimeout function is called and the timer thread adds a timer task. After the setImmediate function is called, its callback function is immediately pushed to the check queue. The main thread has completed execution.

When eventloop determines that there is content in the timers and check queues, it enters asynchronous polling:

The first case: when the time in timers comes, there may not be 1ms left, and the condition of the timer task interval is not met, so there is no callback function in timers. Continue down to the check queue. At this time, the callback function of setImmediate has been waiting for a long time and is executed directly. The next time the eventloop reaches the timers queue, the timer will have matured and the setTimeout callback task will be executed. So the order is "setImmediate -> setTimeout".

The second case: But it is also possible that it exceeds 1ms when it reaches the timers stage. Therefore, the calculation timer condition is met and the setTimeout callback function is executed directly. The eventloop then goes down to the check queue to execute the callback of setImmediate. The final order is "setTimeout -> setImmediate".

Therefore, when only comparing these two functions, the final result of the execution order of the two depends on the current computer's operating environment and operating speed .

Comparison code of the time difference between the two

------------------setTimeout test:-------------------
let i = 0;
console.time('setTimeout');
function test() {
  if (i < 1000) {
    setTimeout(test, 0)
    i++
  } else {
    console.timeEnd('setTimeout');
  }
}
test();

------------------setImmediate test:-------------------
let i = 0;
console.time('setImmediate');
function test() {
  if (i < 1000) {
    setImmediate(test)
    i++
  } else {
    console.timeEnd('setImmediate');
  }
}
test();

Run and observe the time gap:

The time difference between setTimeout and setImmediate

It can be seen that setTimeout takes much more time than setImmediate

This is because setTimeout not only consumes the time of main code execution. Also in the timers queue, there is the calculation time for each scheduled task in the timer thread.

Interview questions related to poll queue (examining the execution order of timers, poll, and check)

If you understand the event loop diagram above, the following question will not be difficult for you!


// Talk about the execution order of the following code, which one will be printed first?
const fs = require('fs')
fs.readFile('./poll.js', () => {
  setTimeout(() => console.log('setTimeout'), 0)
  setImmediate(() => console.log('setImmediate'))
})

No matter how many times the above code logic is executed, setImmediate will always be executed first.

Execute setImmediate first

Because the callbacks of each fs function are placed in the poll queue. When the program is holding in the poll queue, a callback is executed immediately.
After the setTimeout and setImmediate functions are executed in the callback, the check queue is immediately added to the callback.
After the callback is executed, poll other queues to check if there is content, and the program ends the holding of the poll queue and executes downward.
Check is the next phase after poll. Therefore, in the downward process, the callback in the check phase is executed first, that is, setImmediate is printed first.
In the next cycle, when it reaches the timers queue, it checks that the setTimeout timer meets the conditions, and the timer callback is executed.

nextTick and Promise

After talking about macro tasks, let’s talk about micro tasks.

• Both are "micro queues" that execute asynchronous micro tasks.
• The two are not part of the event loop, and the program will not start additional threads to handle related tasks. (Understanding: When a network request is sent in a promise, it is the network thread opened by the network request, which has nothing to do with the microtask of Promise)
• The purpose of setting up a microqueue is to prioritize some tasks "immediately" or "immediately".
• Compared with Promise, nextTick is at a higher level.

NextTick Expression

process.nextTick(() => {})

Promise representation

Promise.resolve().then(() => {})

How to participate in the event loop?

In the event loop, before executing each callback, clear nextTick and promise in sequence.

// Consider the execution order of the following code first setImmediate(() => {
  console.log('setImmediate');
});

process.nextTick(() => {
  console.log('nextTick 1');
  process.nextTick(() => {
    console.log('nextTick 2');
  })
})

console.log('global');


Promise.resolve().then(() => {
  console.log('promise 1');
  process.nextTick(() => {
    console.log('nextTick in promise');
  })
})

Final order:

1. global
2. nextTick 1
3. nextTick 2
4. promise 1
5. nextTick in promise
6. setImmediate

Two questions:

Based on the above, there are two questions to be considered and solved:

1. 1. Check nextTick and promise every time an asynchronous macro task queue is executed? Or should we check it every time a callback function in the macro task queue is executed?
2. 2. If a nextTick or Promise callback is inserted during the holding phase of poll, will the holding of the poll queue be stopped immediately to execute the callback?

For the two questions above, see the code below

setTimeout(() => {
  console.log('setTimeout 100');
  setTimeout(() => {
    console.log('setTimeout 100 - 0');
    process.nextTick(() => {
      console.log('nextTick in setTimeout 100 - 0');
    })
  }, 0)
  setImmediate(() => {
    console.log('setImmediate in setTimeout 100');
    process.nextTick(() => {
      console.log('nextTick in setImmediate in setTimeout 100');
    })
  });
  process.nextTick(() => {
    console.log('nextTick in setTimeout100');
  })
  Promise.resolve().then(() => {
    console.log('promise in setTimeout100');
  })
}, 100)

const fs = require('fs')
fs.readFile('./1.poll.js', () => {
  console.log('poll 1');
  process.nextTick(() => {
    console.log('nextTick in poll ======');
  })
})

setTimeout(() => {
  console.log('setTimeout 0');
  process.nextTick(() => {
    console.log('nextTick in setTimeout');
  })
}, 0)

setTimeout(() => {
  console.log('setTimeout 1');
  Promise.resolve().then(() => {
    console.log('promise in setTimeout1');
  })
  process.nextTick(() => {
    console.log('nextTick in setTimeout1');
  })
}, 1)

setImmediate(() => {
  console.log('setImmediate');
  process.nextTick(() => {
    console.log('nextTick in setImmediate');
  })
});

process.nextTick(() => {
  console.log('nextTick 1');
  process.nextTick(() => {
    console.log('nextTick 2');
  })
})

console.log('global ------');

Promise.resolve().then(() => {
  console.log('promise 1');
  process.nextTick(() => {
    console.log('nextTick in promise');
  })
})

/** The execution order is as follows global ------
nextTick 1
nextTick 2
promise 1
nextTick in promise
setTimeout 0 // Explanation of the problem 1. Without nextTick and promise above, the order of setTimeout and setImmediate is not certain. With them, 0 will definitely start first.
// It can be seen that before executing a queue, nextTick and promise micro queues are checked and executed first. nextTick in setTimeout
setTimeout 1
nextTick in setTimeout1
promise in setTimeout1
setImmediate
nextTick in setImmediate
poll 1
nextTick in poll ======
setTimeout 100
nextTick in setTimeout100
promise in setTimeout100
setImmediate in setTimeout 100
nextTick in setImmediate in setTimeout 100
setTimeout 100 - 0
nextTick in setTimeout 100 - 0
 */

The above code is executed multiple times in the same order, and the order of setTimeout and setImmediate remains unchanged.

The execution order and specific reasons are as follows:

1. global : Main thread synchronization task, first execution is OK
2. nextTick 1 : Before executing the asynchronous macro task, clear the asynchronous micro task, nextTick has a high priority and is executed one step ahead
3. nextTick 2 : After executing the above code, another nextTick microtask is executed immediately
4. promise 1 : Before executing the asynchronous macro task, clear the asynchronous micro task. Promise has a low priority, so it is executed immediately after nextTick is completed.
5. nextTick in promise : When clearing the Promise queue, if a nextTick microtask is encountered, it will be executed and cleared immediately.
6. setTimeout 0 : Explain the first question. Without nextTick and promise above, when there is only setTimeout and setImmediate, their execution order is uncertain. After you have it, you must start from 0. It can be seen that before executing a macro queue, the nextTick and promise micro queues are checked and executed in sequence. When all micro-queues are executed, the timing of setTimeout(0) is ripe and it will be executed.
7. nextTick in setTimeout : After executing the above code, another nextTick microtask is executed first . [I am not sure whether the microtasks in this callback function are executed immediately after the synchronous tasks; or they are put into the microtask queue and cleared before the next macrotask is executed. But the order looks the same as if they were executed immediately. But I prefer the latter: put them in the microtask queue first and wait, and clear them before the next macrotask is executed.
8. setTimeout 1 : Because the execution of the microtask takes time, the two setTimeout timers 0 and 1 in timers have ended, so both setTimeout callbacks have been added to the queue and executed.
9. nextTick in setTimeout1 : After executing the above code, another nextTick microtask is executed first immediately [it may be to clear the microtask before the next macrotask]
10. promise in setTimeout1 : After executing the above code, another Promise microtask is executed immediately [it may be to clear the microtask before the next macrotask]
11. setImmediate : The poll queue callback time has not arrived, so it goes down to the check queue first, clears the queue, and immediately executes the setImmediate callback
12. nextTick in setImmediate : After executing the above code, another nextTick microtask is executed immediately [it may be to clear the microtask before the next macrotask]
13. poll 1 : The poll queue is actually mature, the callback is triggered, and the synchronous task is executed.
14. nextTick in poll : After executing the above code, another nextTick microtask is executed first immediately [it may be to clear the microtask before the next macrotask]
15. setTimeout 100 : When the timer task arrives, the callback is executed. And push nextTick and Promise into the microtask in the callback, and push the setImmediate callback into the check of the macrotask. And also started the timer thread, added the possibility of the next round of callback to the timers.
16. nextTick in setTimeout100 : Before the macro task goes down, the newly added microtask in the timer callback - nextTick is executed first [Here you can determine that it is the process of clearing microtasks before the next macro task]
17. promise in setTimeout100 : immediately execute the newly added microtask in the timer callback - Promise [clear the order of nextTick and then clear the Promise]
18. setImmediate in setTimeout 100 : The reason why setImmediate is executed before setTimeout(0) this time is that the process goes backward from timers to the check queue, and there is already a callback for setImmediate, which is executed immediately.
19. nextTick in setImmediate in setTimeout 100 : After executing the above code, another nextTick microtask is executed. The microtask is cleared before the next macrotask.
20. setTimeout 100 - 0 : Polling returns to timers again and executes the callback of 100-0.
21. nextTick in setTimeout 100 - 0 : After executing the above code, there is another nextTick microtask, and the microtask is cleared before the next macrotask.

Extension: Why do we need nextTick and Promise when we have setImmediate?

When it was first designed, setImmediate acted as a microqueue (although it is not). The designer hopes that setImmediate will be executed immediately after poll is executed (of course, this is indeed the case now). So the name is Immediate , which means立即. But the problem later is that there may be N tasks in poll that are executed continuously, and it is impossible to execute setImmediate during the execution. Because the poll queue is not stopped, the process does not execute downward.

So nextTick, the real micro-queue concept, appeared. But at this time, the name of immediate is taken, so the name is nextTick (next tick). During the event loop, before executing any queue, it is checked whether it is empty. The second is Promise.

Interview Questions

Finally, here comes the interview question to test the learning results

async function async1() {
  console.log('async start');
  await async2();
  console.log('async end');
}

async function async2(){
  console.log('async2');
}
console.log('script start');

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

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

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

process.nextTick(() => {
  console.log('nextTick');
})

async1();

new Promise((res) => {
  console.log('promise1');
  res();
  console.log('promise2');
}).then(() => {
  console.log('promise 3');
});

console.log('script end');

// The answer is as follows // -
// -
// -
// -
// -
// -
// -
// -
// -
// -
// -
// -
/**
script start
async start
async2
promise1
promise2
script end

nextTick
async end
promise 3

// The following three operations are to verify the computing speed of your computer.
The fastest (less than 0ms to execute the above synchronization code + microtask + timer operation):
setImmediate
setTimeout 0
setTimeout 3

The speed is medium (it takes more than 0~3ms to execute the above synchronization code + microtask + timer operation):
setTimeout 0
setImmediate
setTimeout 3

Poor speed (executing the above synchronization code + microtask + timer operation took more than 3ms):
setTimeout 0
setTimeout 3
setImmediate
*/

Mind map

Core phases of the Node life cycle

This is the end of this article on a comprehensive understanding of the Node event loop. For more information about the Node 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!