Home>Article>Web Front-end> What is an event loop? Detailed explanation of the event loop in Node.js
What is an event loop? This article will introduce you to the event loop inNode, I hope it will be helpful to you!
Although JavaScript is single-threaded, the event loop uses the system kernel as much as possible to allowNode.jsto perform non-blocking I/O operations Although most modern kernels are multi-threaded, they can handle multi-threaded tasks in the background. When a task is completed, the kernel tells Node.js, and then the appropriate callback will be added to the loop for execution. This article will introduce this topic in further detail
When Node.js starts executing, it will first initialize the event loop and process the provided input script (or put it into the REPL, which is not covered in this document). This will execute asynchronous API calls and schedule timings. handler, or call process.nextTick(), and then start processing the event loop
The following figure shows a simplified overview of the event loop execution sequence
┌───────────────────────────┐ ┌─>│ timers │ │ └─────────────┬─────────────┘ │ ┌─────────────┴─────────────┐ │ │ pending callbacks │ │ └─────────────┬─────────────┘ │ ┌─────────────┴─────────────┐ │ │ idle, prepare │ │ └─────────────┬─────────────┘ ┌───────────────┐ │ ┌─────────────┴─────────────┐ │ incoming: │ │ │ poll │<─────┤ connections, │ │ └─────────────┬─────────────┘ │ data, etc. │ │ ┌─────────────┴─────────────┐ └───────────────┘ │ │ check │ │ └─────────────┬─────────────┘ │ ┌─────────────┴─────────────┐ └──┤ close callbacks │ └───────────────────────────┘
Each box represents an event loop A stage
Each stage has a FIFO queue callback execution. However, each stage is executed in its own way. Generally speaking, when the event loop enters a stage, it will execute the current For any operation in a stage, callbacks in the queue of the current stage will be executed until the queue is completely consumed or the maximum data of the queue is reached. When the queue is exhausted or reaches its maximum size, the event loop moves to the next phase.
In each process of the event loop , Node.js checks if it is waiting for asynchronous I/O and timers, if not then shuts down completely
A timer specifies the critical point at which a callback will be executed, rather than the time one wants it to execute. The timer will execute as early as possible after the specified elapsed time. However, operating system scheduling or other callbacks can delay its execution.
Technically speaking, the poll phase determines when the callback is executed
For example, you set a timer to execute after 100 ms, but your script reads a file asynchronously It took 95ms
const fs = require('fs'); function someAsyncOperation(callback) { // Assume this takes 95ms to complete fs.readFile('/path/to/file', callback); } const timeoutScheduled = Date.now(); setTimeout(() => { const delay = Date.now() - timeoutScheduled; console.log(`${delay}ms have passed since I was scheduled`); }, 100); // do someAsyncOperation which takes 95 ms to complete someAsyncOperation(() => { const startCallback = Date.now(); // do something that will take 10ms... while (Date.now() - startCallback < 10) { // do nothing } });
When the event loop enters the poll phase, there is an empty queue (fs.readFile() has not completed yet), so it will wait for the remaining milliseconds until the fastest timer threshold Arrives, when 95 ms later, fs.readFile() completes reading the file and will take 10 ms to complete adding to the poll phase and completing execution. When the callback is completed, there are no callbacks in the queue to be executed, and the event loop returns to the timers phase. Execute the timer's callback. In this example, you will see that the timer is delayed for 105 ms and then executed
To prevent the poll phase from blocking the event loop, libuv (the C language library that implements the event loop and all asynchronous behavior on the platform) There is also a maximum value in the poll phase to stop polling for more events
This phase executes callbacks for certain system operations (such as TCP error types). For example, some *nix systems want to wait for an error to be reported if a TCP socket receives ECONNREFUSED when trying to connect. This will be queued for execution during the pending callback phase.
The poll phase has two main functions
When the event loop enters the poll phase and there is no timer, the following two things happen
Once the poll queue is empty, the event loop will detect whether the timer has expired. If so, the event loop will reach the timers stage to execute the timer callback
此阶段允许人们在 poll 阶段完成后立即执行回调。 如果轮询阶段变得空闲并且脚本已使用 setImmediate() 排队,则事件循环可能会继续到 check 阶段而不是等待。
setImmediate() 实际上是一个特殊的计时器,它在事件循环的单独阶段运行。 它使用一个 libuv API 来安排在 poll 阶段完成后执行的回调。
通常,随着代码的执行,事件循环最终会到达 poll 阶段,它将等待传入的连接、请求等。但是,如果使用 setImmediate() 安排了回调并且 poll 阶段变得空闲,它将结束并继续 check 阶段,而不是等待 poll 事件。
如果一个 socket 或者操作突然被关闭(e.g socket.destroy()),close 事件会被发送到这个阶段,否则会通过process.nextTick()发送
setImmediate() 和 setTimeout() 是相似的,但是不同的行为取决于在什么时候被调用
每个回调执行的顺序依赖他们被调用的上下本环境,如果在同一个模块被同时调用,那么时间会受到进程性能的限制(这也会被运行在这台机器的其他应用所影响)
例如,如果我们不在I/O里边运行下面的脚本,尽管它受进程性能的影响,但是不能够确定这两个计时器的执行顺序:
// timeout_vs_immediate.js setTimeout(() => { console.log('timeout'); }, 0); setImmediate(() => { console.log('immediate'); });
$ node timeout_vs_immediate.js timeout immediate $ node timeout_vs_immediate.js immediate timeout
然而,如果你移动到I/O 循环中,immediate 回调总是会先执行
// timeout_vs_immediate.js const fs = require('fs'); fs.readFile(__filename, () => { setTimeout(() => { console.log('timeout'); }, 0); setImmediate(() => { console.log('immediate'); }); });
$ node timeout_vs_immediate.js immediate timeout $ node timeout_vs_immediate.js immediate timeout
setImmediate 相对于 setTimeout 的优势是 setImmediate 如果在I/O 中总是会优先于任何计时器被先执行,与存在多少计时器无关。
尽管 process.nextTick() 是异步API的一部分,但是你可能已经注意到了它没有出现在图表中,这是因为 process.nextTick() 不是事件循环技术的一部分,相反,当前操作执行完毕之后 nextTickQueue 会被执行,无论事件循环的当前阶段如何。 在这里,操作被定义为来自底层 C/C++ 处理程序的转换,并处理需要执行的 JavaScript。 根据图表,你可以在任意阶段调用 process.nextTick(),在事件循环继续执行之前,所有传递给 process.nextTick() 的回调都将被执行,这个会导致一些坏的情况因为它允许你递归调用 process.nextTick() "starve" 你的 I/O ,这会阻止事件循环进入 poll 阶段。
为什么这种情况会被包含在Node.js中?因为Node.js的设计理念是一个API应该总是异步的即使它不必须,看看下面的片段
function apiCall(arg, callback) { if (typeof arg !== 'string') return process.nextTick( callback, new TypeError('argument should be string') ); }
该片段会进行参数检查,如果不正确,它会将错误传递给回调。 API 最近更新,允许将参数传递给 process.nextTick() 允许它接受在回调之后传递的任何参数作为回调的参数传播,因此您不必嵌套函数。
我们正在做的是将错误传回给用户,但前提是我们允许用户的其余代码执行。 通过使用 process.nextTick(),我们保证 apiCall() 总是在用户代码的其余部分之后和允许事件循环继续之前运行它的回调。 为了实现这一点,允许 JS 调用堆栈展开,然后立即执行提供的回调,这允许人们对 process.nextTick() 进行递归调用,而不会达到 RangeError:从 v8 开始超出最大调用堆栈大小。
更多node相关知识,请访问:nodejs 教程!
The above is the detailed content of What is an event loop? Detailed explanation of the event loop in Node.js. For more information, please follow other related articles on the PHP Chinese website!