事件循环阶段解析及作用详解

偷偷努力，悄无声息地变强，然后惊艳所有人！哈哈，小伙伴们又来学习啦~今天我将给大家介绍《事件循环各阶段详解及作用解析》，这篇文章主要会讲到等等知识点，不知道大家对其都有多少了解，下面我们就一起来看一吧！当然，非常希望大家能多多评论，给出合理的建议，我们一起学习，一起进步！

事件循环通过定时器、待定回调、轮询、检查、关闭回调五个阶段有序执行任务，确保异步非阻塞；2. 宏任务（如setTimeout）按阶段执行，微任务（如Promise、process.nextTick）在每个宏任务后优先清空；3. setTimeout(fn, 0)不立即执行因需等当前阶段完成且受最小延迟限制；4. Node.js有明确阶段划分和setImmediate/process.nextTick，浏览器更关注渲染与用户交互，两者微任务机制一致但宏任务来源不同。

事件循环是JavaScript处理异步任务的幕后英雄，它通过一系列有序的阶段，确保代码非阻塞运行，同时协调I/O、定时器和事件回调的执行。简单来说，它就像一个永不停歇的指挥官，不断检查是否有任务需要执行，并按照严格的优先级和流程来调度它们。

解决方案

要理解事件循环的每个阶段具体做了什么，我们通常以Node.js的环境为例，因为它对事件循环的阶段划分最为清晰和明确。我个人觉得，当你真正弄懂了这些阶段，很多看似“奇怪”的异步行为就变得顺理成章了。

事件循环大致可以分为以下几个核心阶段，它们会循环往复地执行：

• 定时器（timers）阶段： 这个阶段主要处理 setTimeout() 和 setInterval() 设定的回调函数。当事件循环进入这个阶段时，它会检查是否有定时器到期，然后执行它们的回调。说实话，很多人以为 setTimeout(fn, 0) 会立刻执行，但它只是“尽快”执行，具体时机还要看事件循环走到哪了，以及前面有没有其他任务。
• 待定回调（pending callbacks）阶段： 这个阶段会执行一些系统操作的回调，比如TCP错误等。这些回调通常是上一个循环中因为某些原因被延迟到当前循环执行的I/O操作回调。
• 空闲、准备（idle, prepare）阶段： 这是Node.js内部使用的阶段，通常不涉及用户代码，可以理解为是事件循环内部的一些准备工作。
• 轮询（poll）阶段： 这是事件循环中一个非常关键的阶段，也是我个人觉得最“忙碌”的阶段。
  • 它首先会检查是否有新的I/O事件（例如文件读写完成、网络请求响应等）。如果有，它会执行对应的回调函数。
  • 如果当前没有I/O事件，它会检查 setImmediate() 设定的回调函数队列。如果队列里有任务，它会立即跳转到 check 阶段去执行它们。
  • 如果 setImmediate() 队列也空了，那么事件循环可能会在这里等待新的I/O事件到来。当然，如果定时器已经到期，它也会直接跳回 timers 阶段去处理。
• 检查（check）阶段： 这个阶段专门用来执行 setImmediate() 设置的回调函数。我经常看到有人疑惑 setTimeout(fn, 0) 和 setImmediate(fn) 的执行顺序，理解了这个阶段，答案就清晰了：setImmediate 优先级通常在I/O回调之后，但在下一个事件循环的定时器之前。
• 关闭回调（close callbacks）阶段： 这个阶段会执行一些关闭事件的回调，比如 socket.on('close', ...) 这样的回调。当一个句柄或资源被关闭时，相应的回调会在这里执行。

值得一提的是，在每个阶段的间隙，以及一个宏任务（比如一个定时器回调或一个I/O回调）执行完毕后，微任务队列（Microtask Queue）会被清空。这包括 process.nextTick() 和 Promise 的回调。process.nextTick 优先级极高，它几乎是在当前代码执行完后，立即在当前阶段内执行，甚至比Promise回调还要早。

微任务与宏任务：它们在事件循环中扮演了怎样的角色？

微任务和宏任务是理解事件循环优先级绕不开的两个概念，它们就像事件循环的左右手，共同协作。说实话，刚开始接触时，我常常把它们混淆，但一旦你掌握了它们的执行时机，很多异步代码的输出就变得可预测了。

宏任务（Macrotasks），或者更准确地说是“任务”，是事件循环的每次迭代中执行的主要工作单元。它们包括：

• setTimeout() 和 setInterval() 的回调
• I/O 操作的回调（例如文件读写、网络请求）
• setImmediate() 的回调（Node.js特有）
• UI渲染事件（浏览器特有）

每次事件循环的一个阶段完成，或者一个宏任务执行完毕后，事件循环会检查并清空微任务队列。

微任务（Microtasks） 则是更细粒度的任务，它们具有更高的优先级。在当前宏任务执行完毕后，以及下一个宏任务开始之前，所有待执行的微任务都会被清空。这意味着，即使你设置了一个 setTimeout(0)，如果前面有一个Promise回调，Promise回调也会先于 setTimeout(0) 执行。 常见的微任务包括：

• Promise.then(), Promise.catch(), Promise.finally() 的回调
• process.nextTick() 的回调（Node.js特有，优先级甚至高于Promise）
• MutationObserver 的回调（浏览器特有）

它们的关系是这样的： 事件循环会取出一个宏任务执行。当这个宏任务执行完毕后，不是立即开始下一个宏任务，而是会暂停，去检查并清空所有的微任务队列。只有当微任务队列被彻底清空后，事件循环才会继续下一个宏任务，或者进入下一个阶段。这种机制确保了微任务能够更快地响应，因为它插队在宏任务之间。我个人觉得，这种设计非常精妙，它让一些需要即时响应但又不希望阻塞主线程的操作得以实现。

为什么setTimeout(fn, 0)不总是立即执行？

这是一个经典问题，也是很多初学者容易被“零延迟”这个词误导的地方。当你写下 setTimeout(fn, 0) 时，你的本意可能是希望 fn 能够“立刻”执行，但实际上，它只是将 fn 推入到定时器队列中，并告诉事件循环：“嘿，这个函数可以等0毫秒后执行了。”至于它什么时候真正被执行，那就得看事件循环的脸色了。

原因在于：

1. 事件循环的阶段性： setTimeout 的回调是在事件循环的 timers 阶段处理的。在进入 timers 阶段之前，事件循环可能还在处理 pending callbacks 阶段，或者正在 poll 阶段等待I/O事件。如果这些阶段有任务，或者主线程有同步代码正在执行，那么 setTimeout(0) 的回调就必须等待。
2. 最小延迟保证： 即使设置了0毫秒，浏览器和Node.js通常也有一个最小的延迟时间（比如4毫秒），这主要是为了节约系统资源，防止过于频繁的定时器调度。所以，0毫秒实际上可能变成4毫秒。
3. 微任务的优先级： 即使定时器到期了，如果当前正在执行的宏任务产生了微任务（比如一个Promise），那么这些微任务会先于下一个宏任务（包括 setTimeout 回调）执行。这进一步推迟了 setTimeout(0) 的实际执行时间。

举个例子，如果你有一段很长的同步计算代码，或者一个耗时的I/O操作正在进行，setTimeout(0) 的回调就得等它们全部完成，并且事件循环走到 timers 阶段时才能被执行。它不像 process.nextTick 那样，几乎是紧接着当前代码执行，而是要排队等候。所以，用“尽快”来描述 setTimeout(0) 的执行时机，比“立即”要准确得多。

Node.js与浏览器环境下的事件循环有何异同？

虽然都是基于事件循环来处理异步，但Node.js和浏览器环境下的事件循环在实现细节和侧重点上存在一些显著的差异，这主要源于它们各自的应用场景和核心需求。我个人觉得，理解这些异同，能让你更深刻地把握JavaScript在不同环境下的行为模式。

相似之处：

• 单线程执行JS： 两者都保持JavaScript代码在主线程上单线程执行，避免了多线程带来的复杂性。
• 异步非阻塞： 都通过事件循环机制实现异步非阻塞I/O，确保长时间运行的操作不会阻塞主线程。
• 微任务队列： 都支持微任务队列（如Promise回调），并且微任务的优先级高于宏任务，会在当前宏任务执行完毕后立即清空。

不同之处：

1. 阶段划分：
   • Node.js： 具有明确的、细致的阶段划分（timers, pending callbacks, poll, check, close callbacks），这些阶段由底层的 libuv 库实现，专注于高效的I/O操作。
   • 浏览器： 通常没有Node.js那样明确的阶段概念，更多地被描述为“任务队列”（macrotask queue）和“微任务队列”（microtask queue）。浏览器环境的事件循环更关注UI渲染、用户交互、网络请求等，其任务源更为多样。
2. 特定API：
   • Node.js： 拥有 process.nextTick()（优先级极高的微任务）和 setImmediate()（在 check 阶段执行的宏任务），这些API是Node.js特有的。
   • 浏览器： 拥有 requestAnimationFrame()（用于优化动画和渲染）、requestIdleCallback()（在浏览器空闲时执行任务）、MutationObserver（用于监听DOM变化，作为微任务）等API，这些是浏览器环境独有的，服务于前端交互和性能优化。
3. I/O模型：
   • Node.js： 核心是基于 libuv 库实现的异步I/O模型，它将底层系统调用抽象化，并与事件循环紧密集成，以处理文件系统、网络等操作。
   • 浏览器： 内部的I/O模型更复杂，涉及到网络请求（XMLHttpRequest, Fetch API）、DOM事件、Web Workers等，这些操作的回调也会被推入任务队列。

总的来说，Node.js的事件循环更偏向于服务器端的I/O密集型任务处理，其阶段设计是为了最大化I/O效率；而浏览器的事件循环则更侧重于用户界面的响应性和渲染性能。尽管底层实现有所差异，但它们都殊途同归，旨在提供一个高效、非阻塞的异步编程模型。

本篇关于《事件循环阶段解析及作用详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！