Shulou(Shulou.com)06/02 Report--

This article mainly introduces "analyzing the event-loop mechanism in Node.js". In the daily operation, I believe that many people have doubts in analyzing the event-loop mechanism in Node.js. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "analyzing the event-loop mechanism in Node.js". Next, please follow the editor to study!

Libuv

Before learning event-loop, take a look at node's libuv. Libuv is responsible for the implementation of different Icano models on different operating systems, and abstracts different implementations into API that can be applied with third-party applications.

problem

Before formally learning event-loop, think about a question.

SetTimeout () = > {console.log ("timer1"); Promise.resolve (). Then (() = > {console.log ("promise1");});}, 0); setTimeout () = > {console.log ("timer2"); Promise.resolve (). Then () = > {console.log ("promise2");};}, 0)

What is the result of this code running in the browser?

What is the result of running in node?

Before node8.6:

After node8.6:

Why there is such a result, we will analyze it later!

Event-loop in nodeJs

First, take a look at a picture:

You can see six phases in the figure, namely: timers,pending callbacks,idle/prepare,poll,check,close callbacks.

Timers phase: mainly executes the callback of setTimeOut,setInterval

Pending callbacks phase: execute some system call errors, such as network communication error callback

Idle/prepare phase: only used within the system (at this stage we can't control and interfere)

Poll phase: get a new Imax O event, such as a callback to read the file. Where appropriate, nodejs will block at this stage

Check phase: execute the callback of setImmediate

For example, execute the destory,close event callback of sokect

Each phase follows a FIFO (first in first out) rule to perform tasks in the task queue. In these six stages, we need to focus on the timers,poll,check phase. Most of the asynchronous tasks in our daily development are handled in these three phases.

Timers

Let's talk about the timers phase first.

Timers is the first phase of the event loop, and nodejs checks to see if there is an expired timer, and if so, puts its callback in the queue. However, nodejs cannot guarantee that timer will immediately execute a callback when a preset event arrives, because nodejs's expiration check for timer may not be reliable, it will be affected by other running programs on the machine, or it will encounter a situation in which the current main thread is not idle.

For the uncertainty here, an example is given on the official website:

First declare a setTimeOut, and then read a file externally. When the read file operation exceeds the timer, the read file operation will postpone the callback of the timer. This is the situation in which the main thread mentioned earlier is not idle.

Poll

The poll phase mainly performs two things:

1. Process the task queue in the poll phase

2. When a timer that has timed out executes its callback function

In the figure above, we can also see that after executing the tasks of the poll task queue in the poll phase, we will check to see if there is a preset setImmediate. If so, we will enter the check phase. If not, the nodejs will block here.

Here we will have a question, if blocking in the poll phase, then the timer we set can not be executed?

In fact, when event-loop blocks in the poll phase, nodejs has a check mechanism to check whether the timers queue is empty, and if not, re-enter the timers phase.

Check

The callback function of setImmediate is mainly executed in the check phase.

Small summary

Each phase of the event-loop has a queue, and when the event-loop reaches a certain stage, the task queue for that phase will be executed until the queue is empty or the maximum callback limit specified by the system is reached before moving on to the next phase. When all phases are executed once, event-loop is said to have completed a tick.

Case

We have finished the theoretical part of event-loop above, but we still can not clearly understand event-loop with theory alone. Let's take a closer look at event-loop based on a few demo!

Demo1

Const fs=require ('fs') fs.readFile (' test.txt', () = > {console.log ('readFile') setTimeout () = > {console.log (' settimeout');}, 0) setImmediate (() = > {console.log ('setImmediate')})})

Execution result:

It can be seen that the implementation result is consistent with our previous analysis!

Demo2

Const fs = require ("fs"); const EventEmitter = require ("events"). EventEmitter; let pos = 0; const messenger = new EventEmitter (); messenger.on ("message", function (msg) {console.log (+ + pos + "message:" + msg); console.log (+ + pos + "first"); / / process.nextTick (function () {console.log (+ + pos + "nextTick"); / /})) Messenger.emit ("message", "hello!"); fs.stat (_ _ filename, function () {console.log (+ + pos + "stat"); / /}); setTimeout (function () {console.log (+ + pos + "quick timer"); / /}, 0); setTimeout (function () {console.log (+ + pos + "long timer"); / /}, 30) SetImmediate (function () {console.log (+ pos + "immediate"); / /}); console.log (+ + pos + "last"); / /

Results:

Find out what is the difference between the event-loop of browser and node

Before node 8.6:

The micro-task queue in the browser is executed after each macro task is completed, while the micro-task in node is executed between the stages of the event loop, that is, the micro-task queue is executed after each phase is completed.

After 8.6:

The execution of micro tasks in browsers and node is the same!

Therefore, at the beginning of the article, the question we raised for thinking has come to a conclusion.

About process.nextTick () and setImmediateprocess.nextTick ()

Syntax: process.nextTick (callback,agrs)

Timing of execution:

This function is actually independent of Event Loop, it has its own queue, when each phase is completed, if there is a nextTick queue, it clears all callback functions in the queue and takes precedence over other microtask execution. A recursive call to process.nextTick () will result in I starving O starving. It is officially recommended to use setImmediate ().

An explanation of the starving phenomenon:

Const fs = require ("fs"); fs.readFile ("test.txt", (err, msg) = > {console.log ("readFile");}); let index = 0; function handler () {if (index > = 30) return; index++; console.log ("nextTick" + index); process.nextTick (handler);} handler ()

Running result:

As you can see, the callback for reading the file is not executed until the nextTick function is executed 30 times! This phenomenon is known as "Ihammer O Hunger".

When we change process.nextTick to setImmediate,

Const fs = require ("fs"); fs.readFile ("test.txt", (err, msg) = > {console.log ("readFile");}); let index = 0; function handler () {if (index > = 30) return; index++; console.log ("nextTick" + index); setImmediate (handler);} handler ()

Results:

The reason for the difference between the two is that the callback of the nested call setImmediate is scheduled into the next event-loop!

Event-loop core mind map

At this point, the study on "analyzing the event-loop mechanism in Node.js" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.