Node.js的事件循环如何实现？这篇带你明白
发布时间：2022-02-08 15:31:14 所属栏目：编程 来源：互联网
导读：这篇文章给大家分享的是Node.js的事件循环的实现，对于事件循环的六个阶文中都有很详细的介绍，下文还有示例可以参考，对大家学习和理解Node.js的事件循环会有帮助，有需要的朋友可以了解看看这篇，接下来就跟随小编一起学习一下吧。 Node.js是单线程的语言
|
这篇文章给大家分享的是Node.js的事件循环的实现，对于事件循环的六个阶文中都有很详细的介绍，下文还有示例可以参考，对大家学习和理解Node.js的事件循环会有帮助，有需要的朋友可以了解看看这篇，接下来就跟随小编一起学习一下吧。 Node.js是单线程的语言，是通过事件循环处理非阻塞I/O操作的。Node.js 做为 JavaScript 的服务端运行时，主要与网络、文件打交道，没有了浏览器中事件循环的渲染阶段。 在浏览器中有 HTML 规范来定义事件循环的处理模型，之后由各浏览器厂商实现。Node.js 中事件循环的定义与实现均来自于 Libuv。 Libuv 围绕事件驱动的异步 I/O 模型而设计，最初是为 Node.js 编写的，提供了一个跨平台的支持库。下图展示了它的组成部分，Network I/O 是网络处理相关的部分，右侧还有文件操作、DNS，底部 epoll、kqueue、event ports、IOCP 这些是底层不同操作系统的实现。 事件循环的六个阶段 当 Node.js 启动时，它会初始化事件循环，处理提供的脚本，同步代码入栈直接执行，异步任务（网络请求、文件操作、定时器等）在调用 API 传递回调函数后会把操作转移到后台由系统内核处理。目前大多数内核都是多线程的，当其中一个操作完成时，内核通知 Node.js 将回调函数添加到轮询队列中等待时机执行。 下图左侧是 Node.js 官网对事件循环过程的描述，右侧是 Libuv 官网对 Node.js 的描述，都是对事件循环的介绍，不是所有人上来都能去看源码的，这两个文档通常也是对事件循环更直接的学习参考文档，在 Node.js 官网介绍的也还是挺详细的，可以做为一个参考资料学习。 左侧 Node.js 官网展示的事件循环分为 6 个阶段，每个阶段都有一个 FIFO（先进先出）队列执行回调函数，这几个阶段之间执行的优先级顺序还是明确的。 右侧更详细的描述了，在事件循环迭代前，先去判断循环是否处于活动状态（有等待的异步 I/O、定时器等），如果是活动状态开始迭代，否则循环将立即退出。 下面对每个阶段分别讨论。 timers（定时器阶段） 首先事件循环进入定时器阶段，该阶段包含两个 API setTimeout(cb, ms)、setInterval(cb, ms) 前一个是仅执行一次，后一个是重复执行。 这个阶段检查是否有到期的定时器函数，如果有则执行到期的定时器回调函数，和浏览器中的一样，定时器函数传入的延迟时间总比我们预期的要晚，它会受到操作系统或其它正在运行的回调函数的影响。 例如，下例我们设置了一个定时器函数，并预期在 1000 毫秒后执行。 const now = Date.now(); setTimeout(function timer1(){ log(`delay ${Date.now() - now} ms`); }, 1000); setTimeout(function timer2(){ log(`delay ${Date.now() - now} ms`); }, 5000); someOperation(); function someOperation() { // sync operation... while (Date.now() - now < 3000) {} } 当调用 setTimeout 异步函数后，程序紧接着执行了 someOperation() 函数，中间有些耗时操作大约消耗 3000ms，当完成这些同步操作后，进入一次事件循环，首先检查定时器阶段是否有到期的任务，定时器的脚本是按照 delay 时间升序存储在堆内存中，首先取出超时时间最小的定时器函数做检查，如果 nowTime - timerTaskRegisterTime > delay 取出回调函数执行，否则继续检查，当检查到一个没有到期的定时器函数或达到系统依赖的最大数量限制后，转移到下一阶段。 在我们这个示例中，假设执行完 someOperation() 函数的当前时间为 T + 3000： 检查 timer1 函数，当前时间为 T + 3000 - T > 1000，已超过预期的延迟时间，取出回调函数执行，继续检查。 检查 timer2 函数，当前时间为 T + 3000 - T < 5000，还没达到预期的延迟时间，此时退出定时器阶段。 pending callbacks 定时器阶段完成后，事件循环进入到 pending callbacks 阶段，在这个阶段执行上一轮事件循环遗留的 I/O 回调。根据 Libuv 文档的描述：大多数情况下，在轮询 I/O 后立即调用所有 I/O 回调，但是，某些情况下，调用此类回调会推迟到下一次循环迭代。听完更像是上一个阶段的遗留。 idle, prepare idle, prepare 阶段是给系统内部使用，idle 这个名字很迷惑，尽管叫空闲，但是在每次的事件循环中都会被调用，当它们处于活动状态时。这一块的资料介绍也不是很多。略... poll poll 是一个重要的阶段，这里有一个概念观察者，有文件 I/O 观察者，网络 I/O 观察者等，它会观察是否有新的请求进入，包含读取文件等待响应，等待新的 socket 请求，这个阶段在某些情况下是会阻塞的。 阻塞 I/O 超时时间 在阻塞 I/O 之前，要计算它应该阻塞多长时间，参考 Libuv 文档上的一些描述，以下这些是它计算超时时间的规则： 如果循环使用 UV_RUN_NOWAIT 标志运行、超时为 0。 如果循环将要停止（uv_stop() 被调用），超时为 0。 如果没有活动的 handlers 或 request，超时为 0。 如果有任何 idle handlers 处于活动状态，超时为 0。 如果有任何待关闭的 handlers，超时为 0。 如果以上情况都没有，则采用最近定时器的超时时间，或者如果没有活动的定时器，则超时时间为无穷大，poll 阶段会一直阻塞下去。 示例一 很简单的一段代码，我们启动一个 Server，现在事件循环的其它阶段没有要处理的任务，它会在这里等待下去，直到有新的请求进来。 const http = require('http'); const server = http.createServer(); server.on('request', req => { console.log(req.url); }) server.listen(3000); 示例二 结合阶段一的定时器，在看个示例，首先启动 app.js 做为服务端，模拟延迟 3000ms 响应，这个只是为了配合测试。再运行 client.js 看下事件循环的执行过程： 首先程序调用了一个在 1000ms 后超时的定时器。 之后调用异步函数 someAsyncOperation() 从网络读取数据，我们假设这个异步网路读取需要 3000ms。 当事件循环开始时先进入 timer 阶段，发现没有超时的定时器函数，继续向下执行。 期间经过 pending callbacks -> idle,prepare 当进入 poll 阶段，此时的 http.get() 尚未完成，它的队列为空，参考上面 poll 阻塞超时时间规则，事件循环机制会检查最快到达阀值的计时器，而不是一直在这里等待下去。 当大约过了 1000ms 后，进入下一次事件循环进入定时器，执行到期的定时器回调函数，我们会看到日志 setTimeout run after 1003 ms。 在定时器阶段结束之后，会再次进入 poll 阶段，继续等待。 // client.js const now = Date.now(); setTimeout(() => log(`setTimeout run after ${Date.now() - now} ms`), 1000); someAsyncOperation(); function someAsyncOperation() { http.get('http://localhost:3000/api/news', () => { log(`fetch data success after ${Date.now() - now} ms`); }); } // app.js const http = require('http'); http.createServer((req, res) => { setTimeout(() => { res.end('OK!') }, 3000); }).listen(3000); 当 poll 阶段队列为空时，并且脚本被 setImmediate() 调度过，此时，事件循环也会结束 poll 阶段，进入下一个阶段 check。 check check 阶段在 poll 阶段之后运行，这个阶段包含一个 API setImmediate(cb) 如果有被 setImmediate 触发的回调函数，就取出执行，直到队列为空或达到系统的最大限制。 setTimeout VS setImmediate （编辑：宿州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |