原文=> What you should know to really understand the Node.js Event Loop
Node.js 是一个基于事件的平台。这就意味着在Node中发生的所有事情都是对事件的反应。在 Node 中调用是通过一系列回调完成的。
在开发者看来,这一切都由一个名为 libuv 的库处理,它提供了一种称为事件循环的机制。
事件循环机制也许是在整个环境中最被误解的概念
常见的误解
误解1:时间循环和用户代码跑在不同的线程当中
原因:用户的代码跑在主线程中,事件循环则在另外一个线程,每次执行回调,主线程将工作交给事件循环完成,然后事件循环将 ping 主线程进行回调
真实的:只有一个线程在执行 JS 代码,这个线程就是事件循环运行的线程。
执行回调(知道正在运行的node.js应用程序中的每个用户级代码都是回调)由事件循环完成。我们稍后会深入讨论这一点。
误解2:所有异步事件都由线程池处理
原因:异步操作(如使用文件系统)执行出站 HTTP 请求或与数据库交谈始终加载到由 libuv 提供的线程池。
真实的:默认情况下,libuv创建一个包含四个线程的线程池,以将异步工作分流。如今的操作系统已经为许多I / O任务提供了异步接口(例如 Linux 的 aio)。只要有可能,libuv就会使用这些异步接口,避免使用线程池。这同样适用于数据库等第三方子系统。在这里,驱动程序的作者宁愿使用异步接口,而不使用线程池。简而言之:只有在没有其他方式时,线程池才会用于异步I / O。
误解3:事件循环就像堆栈或者队列一样
原因:事件循环不断在遍历一系列异步任务,并在任务完成时执行回调
真实的:虽然涉及到队列式结构,但事件循环不会贯穿并处理堆栈。事件循环作为一个过程是一组阶段,其中包含以循环方式处理的特定任务。
了解事件循环的生命周期
要真正了解事件循环,应该清楚各个工作分别在那个阶段完成了任务。下图将会展示事件循环是如何工作的
具体请前往 => The Node.js Event Loop, Timers, and process.nextTick() | Node.js
计时器
通过 setTimeout() 或 setInterval() 计划的所有内容都将在此处理。
IO 回调
在这里所有的回调都会被处理。由于 node 中所有业务代码都是基于回调的。(例如,对传入http请求的回调触发级联回调),因此这是处理业务代码的阶段。
IO 轮询
投票处理下一次处理的新事件
立即设置
运行通过 setImmediate() 注册的所有回调
关闭
执行所有的 (‘close’) 回调
工作处理延迟
此度量标准测量线程池处理异步任务需要多长时间。高工作时间处理延迟表明繁忙/耗尽的线程池。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。