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

This article mainly introduces "NodeJS event loop case analysis". In daily operation, I believe many people have doubts about NodeJS event loop case analysis. The editor consulted all kinds of data and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts of "NodeJS event loop case analysis". Next, please follow the editor to study!

There are two task queues in the browser, one is a macro task and the other is a micro task. But there are six event queues in NodeJS, timers,pending callbacks,idle prepare,poll,check,close callbacks. Stored in each queue is the callback function callback.

The six queues are executed sequentially. Each queue is responsible for storing different tasks.

What exists in timer is the callback function of setTimeout and setInterval

Pending callback is a callback that executes the operating system, such as tcp,udp.

Idle and prepare are used only within the system. Ordinary developers don't need it.

Poll performs callback operations related to IO

The callback in setImmediate is stored in check.

Close callbacks performs a callback for the close event.

In Node, when the code is executed synchronously from top to bottom, different tasks will be added to the corresponding queue during execution. For example, setTimeout will be placed in timers, and if a file is read or written, it will be placed in poll. After the entire synchronized code is executed, it will perform micro-tasks that meet the conditions. You can imagine that there is a queue for storing microtasks that has nothing to do with the previous six.

When the synchronization code is completed, the micro-tasks that meet the conditions will be executed, and once all the micro-tasks have been executed, the macro tasks that meet the conditions in the queue will be executed in the order listed above.

First of all, he will execute the macro tasks that meet the conditions in the timers. When he completes the tasks satisfied in the timers, he will perform the queue switch and empty the micro tasks in the micro task list before switching.

So there are two opportunities for micro-task execution, the first time is when all the synchronization code is finished, and the second time before the queue switch.

Note that the execution priority of nextTick is higher than that of Promise in micro tasks, which can only be memorized.

SetTimeout () = > {console.log ('s1');}) Promise.resolve (). Then () = > {console.log (' p1');}) console.log ('start'); process.nextTick () = > {console.log (' tick');}) setImmediate (() = > {console.log ('st');}) console.log (' end'); / / start end tick p1s1 stsetTimeout (()) = > {console.log ('s1') Promise.resolve () .then () = > {console.log ('p1');}) process.nextTick (() = > {console.log (' t1');})}) Promise.resolve (). Then () = > {console.log ('p2')}) console.log (' start'); setTimeout () = > {console.log ('s2') Promise.resolve () .then (() = > {console.log ('p3');}) process.nextTick (() = > {console.log (' t2');})) console.log ('end'); / / start end p2s1s2t1t2p3

There are some differences between Node and browser event ring execution.

First of all, the number of task queues is different. Browsers generally have only two queues of macro tasks and micro tasks, while there are 6 event queues in Node in addition to micro task queues.

Secondly, the timing of micro-task execution is different, but they also have something in common, that is, after the synchronous task is executed, they all go to see if the micro-task is executable. For browsers, the queue of micro-tasks is emptied every time a macro task is executed. In Node, the micro-task queue is emptied only when the event queue is switched.

Finally, micro-task execution is prioritized on the Node platform, nextTick takes precedence over Promise.then, and browsers are first-in, first-out.

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

In Node, sometimes output timeout first and then output immdieate first, this is because setTimeout needs to receive a time parameter, if it is not written, it is a 0, we all know that whether in Node or in the browser, the program can not really be 0, it will be affected by many factors. It depends on the environment in which it is running.

If the setTimeout executes first, it will be placed in the timers queue, so the timeout will type first, and if the setTimeout executes for some reason, then the immdieate in the check queue will execute first. This is why sometimes output timeout and then output immdieate.

Const fs = require ('fs'); fs.readFile ('. / a.txtforth, () = > {setTimeout (()) = > {console.log ('timeout');}, 0) setImmediate (() = > {console.log (' immdieate');})})

In this case, the immdieate will always be output first and then the timeout, because when the code is executed, the timeout will be added to the timers, the callback of fs will be added to poll, and immdieate will be added to the check. After the callback execution of fs is completed, the poll queue will be checked first when the queue is switched, but if there is no micro task, it will continue to go down. Here is the check queue instead of the timers queue, so after poll is cleared, it will switch to the check queue and perform the immdieate callback.

At this point, the study on "NodeJS event loop instance analysis" 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.