JavaScript事件循环与异步机制

July 25, 2024December 25, 2024

本文主要说明现代浏览器以及 Node.js 环境下的 Event Loop

异步任务

异步任务在事件循环中调度执行。ECMA262 规范不规定“何时调度”异步任务（规范称之为 Job），与运行时相关（host-defined）。

注：没有定义调度，但定义了 hooks 通知宿主环境来调度，例如 HostEnqueuePromiseJob

Job 是一种无参数的抽象闭包，当没有其它 ECMAScript 计算正在进行时，它会启动一个 ECMAScript 计算。
在未来某个时间点，当 Job 所属 agent 中没有运行中的上下文且该 agent 的执行上下文堆栈为空时，必须：

执行任何宿主定义的准备步骤。
调用 Job 抽象闭包。（注：可以是将 Job 的执行上下文推入执行上下文堆栈）
执行任何宿主定义的清理步骤，之后执行上下文堆栈必须为空。（注：即 Job 的执行上下文必须弹出。这里实际上隐含地告诉我们 Job 必然是在 Global code 执行后再执行）

执行上下文来源：Global code，Eval code，Function code，Module code

代码由 agent 执行，执行在 agent 的执行上下文中。
agent 包括一组 ECMAScript 执行上下文、执行上下文堆栈、运行中的执行上下文、Agent Record 和执行线程。
除了执行线程之外，代理的组成部分只属于该代理。

规定：

同一时间内，agent 中只能执行单个 job （job 不能并行）
job 一旦开始执行，就不能被打断（抢占）（job 不能并发）

这与 C 语言不同。例如，如果函数在线程中运行，它可能在任何位置被终止，然后在另一个线程中运行其它代码。

注意：job 本身不能并行/并发，但如果是调用宿主环境的函数，宿主函数和当前 ECMAScript 执行当然不禁止并行。
比如，浏览器中执行 fetch 函数时，网络请求并非由 ECMAScript 发出，网络请求和脚本执行可以并行，只是请求完成的回调会成为 job。
job 之间不并行实际上防止了脚本之间发生可观察到的数据竞争。

事件循环

除了 ECMA262 定义的：

执行上下文堆（对象被分配在堆中）
执行上下文栈（函数调用形成了一个由若干帧组成的栈，下面可能简称为调用栈）

运行时内部实现任务队列，往往分为（下面使用 v8 术语，微任务之外都称为宏任务）：

宏任务队列（存储稍后要执行的其它任务）
微任务队列（存储应该在最近的将来调用的任务）

一旦调用栈为空（JavaScript 执行上下文栈清空之后），~~事件循环从任务队列中取出任务来执行~~
解释器从任务队列中取出任务执行（更精确的说法是宿主将一些任务推入执行上下文堆栈），而事件循环接受任务并将任务加入任务队列

运行任务的具体步骤是实现定义的，例如：宿主环境可以通过将执行上下文推入执行上下文堆栈来准备执行。

事件循环能够协调事件、用户交互、脚本、渲染、网络等。每个 agent 有唯一关联的事件循环。

HTML 标准中定义了如何调度异步任务（注意不要与 v8 术语混淆）。
根据 HTML 标准，事件循环中可以有一个或多个任务队列，而微任务队列不是任务队列。

Note

本文只讨论主线程上的事件循环，即标准所称的窗口事件循环

事件循环包含：

一个或多个任务队列。每个任务是一个结构，包含任务步骤、任务来源（用于对相关任务进行分组和序列化）、关联文档和执行环境。
一个微任务队列。

事件循环过程任务执行过程具体见标准 8.1.7.3节。

简单来说：

对于每个事件循环，每个任务源必须与特定的任务队列相关联。
事件循环从具有至少一个可运行任务的任务队列中选取一个任务队列（微任务队列不是任务队列）
每运行完一个任务，就将该任务从任务队列中移除，并执行微任务检查点。
执行微任务检查点会运行微任务队列中的所有任务，直至微任务队列为空。

此外，浏览器将并行页面渲染（update the rendering:）。但每次事件循环不一定能够完成一次渲染。

Warning

水平有限，本文仅作参考，必须以规范为准。

实际情况中我们可以发现，当脚本本身运行结束后，是先运行了微任务再是宏任务。
这是因为规范中指明了此时将微任务移动到常规任务队列，也就是说这个微任务变成了宏任务。

在 Chrome 中，事件循环由 libevent 提供
在 Nodejs 中，事件循环由 libuv 提供

一个演示 WebApp：https://github.com/Hopding/js-visualizer-9000-client

在下面的演示代码中需要注意：浏览器的 console.log 为同步，Node.js 为异步。

浏览器

注意：HTML 标准中只存在任务和 微任务。“宏任务”并没有精确定义，下面通俗地用“宏任务”代替所有非微任务

在浏览器中，queueMicrotask Promise.prototype.then 和 Mutation Observer API 的回调函数使用微任务队列。

宏任务队列可以是一个或多个队列，具体实现方式与浏览器有关。
setTimeout setInterval requestAnimationFrame requestIdleCallback 以及其它事件 API 都使用宏任务。

现代浏览器遵循 HTML 标准

规范定义了如下几种通用任务源：

DOM 操作任务源
用户交互任务源
网络任务源
导航和（历史）遍历任务源
渲染任务源

根据事件循环的特性，微任务队列中的所有微任务会依次出队直至队列为空。
任务也可以在队列中新增任务，这就可能导致队列中永远有任务。
由于在现代浏览器中，微任务队列优于宏任务队列运行。
引擎会调度微任务队列中的所有任务，直至队列为空。但宏任务则不是。
（即，一个宏任务，在宏任务队列中新增宏任务，再新增微任务，微任务先执行）
因此如果微任务队列不为空，宏任务将无法得到执行。反之则不会。

setTimeout(() => {
    console.log("macro"); // 永远不会运行
});
function recursiveMicroTask() {
    queueMicrotask(() => {
        console.log("micro");
        recursiveMicroTask();
    });
}
recursiveMicroTask();

此外，在现代浏览器中，冒泡中的所有事件是按冒泡顺序先添加至宏任务队列中的，然后再执行之。

摘自 https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/

html

<div class="outer">
    <div class="inner"></div>
</div>

const outer = document.querySelector(".outer");
const inner = document.querySelector(".inner");

// 监听元素属性变化
new MutationObserver(function () {
    console.log("mutate");
}).observe(outer, {
    attributes: true,
});

function onClick() {
    console.log("click");

    setTimeout(function () {
        console.log("timeout");
    }, 0);

    Promise.resolve().then(function () {
        console.log("promise");
    });

    outer.setAttribute("data-random", Math.random());
}

inner.addEventListener("click", onClick);
outer.addEventListener("click", onClick);

现代浏览器的结果都是：

click
promise
mutate
click
promise
mutate
timeout
timeout

注： setImmediate 在现代浏览器中不存在（废弃），被 Node.js 实现（未废弃），参见下面的 Node.js 部分

根据 HTML 标准，Web workers 在专用的单独线程上运行，其全局环境为 WorkerGlobalScope。但 Javascript 中上下文之间是隔离的，因此只能通过事件通信，只有 Transferable 对象允许共享内存。
由于不共享内存，消息必须经过序列化（通过结构化克隆算法）。我们手动创建的值，对象以及二进制数组都是可克隆的。但是 WebAPI 获取的对象，例如 DOM 就无法克隆了。（特别是在早期的 IE 中，其本质可能是一个 C++ 对象）

Transferable 对象的所有权问题，超出了本文的范畴

根据 HTML 标准，Worklets 可独立于主 Javascript 环境运行脚本，其全局环境为 WorkletGlobalScope。Worklets 与线程无关（可以运行在任何线程，包括主线程）。既然独立，那就可以实现与其它环境并行。
目前在 CSS Painting API 和 Web Audio API 中提供。

Node.js

摘自：https://nodejs.org/en/learn/asynchronous-work/event-loop-timers-and-nexttick

在 Node.js 中每个队列称为一个阶段（phase）。当事件循环进入给定阶段时，将执行特定于该阶段的任何操作，然后执行该阶段队列中的回调，直到队列耗尽或当最大回调数已执行。
当队列耗尽或达到回调限制时，事件循环将进入下一阶段，依此类推。

Note

Node.js 事件循环负责从 libuv 的队列中取出回调函数，并（调用 v8）在 JavaScript 环境中执行它们。
libuv 事件循环向操作系统轮询事件，当事件发生时，libuv 将对应回调函数添加到其内部的队列中。

计时器 (timers)：此阶段执行被 setTimeout() 和 setInterval() 调度的回调。
挂起的回调 (pending callbacks)：执行延迟到下一个循环迭代的 I/O 回调。
空闲、准备 (idle, prepare)：仅在内部使用。
轮询 (poll)：检索新的 I/O 事件；执行与 I/O 相关的回调（几乎所有回调都是如此，除了关闭回调、计时器调度的回调和 setImmediate() 调度的回调）；适当时，Node.js 将在此处阻塞。
检查 (check)：在此处调用 setImmediate() 回调。
关闭回调 (close callbacks)：一些关闭回调，例如 socket.on('close', ...).

   ┌───────────────────────────┐
┌─>│           timers          │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │     pending callbacks     │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │       idle, prepare       │
│  └─────────────┬─────────────┘      ┌───────────────┐
│  ┌─────────────┴─────────────┐      │   incoming:   │
│  │           poll            │<─────┤  connections, │
│  └─────────────┬─────────────┘      │   data, etc.  │
│  ┌─────────────┴─────────────┐      └───────────────┘
│  │           check           │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
└──┤      close callbacks      │
   └───────────────────────────┘

Node.js 提供了 process.nextTick(callback[, ...args])，而 queueMicrotask(callback)（源码）用于运行 v8 微任务队列。

Note

微任务队列由 v8 维护（MicrotasksQueue），并在执行完一个宏任务（例如一个阶段的事件循环）后，会检查并执行微任务队列中的所有任务，直到队列为空

Node.js 还实现了 process.nextTick，next tick 即事件循环继续之前。
可以将 process.nextTick 看作是 Node.js 自己实现的 queueMicrotask 版本，并且它运行在 v8 微任务之前。
（具体信息，Node.js 文档中已经很详细说明了）

当我们实现一个函数执行回调时，保证回调函数异步执行往往很重要。不过如果使用 Promise 则没有这些烦恼。

function definitelyAsync(arg, cb) {
    if (arg) {
        // 为了互操性建议使用 queueMicrotask 替代
        process.nextTick(cb);
        return;
    }

    fs.stat("file", cb);
}

Node.js 同样支持 Worker 多线程（通过 worker_threads，注意并非是 Web Workers，不过接口确实也仿照其实现）。
众所周知，Node.js 的异步 I/O 机制非常适合 I/O 敏感型任务（并发），对于 CPU 敏感型任务则需要考虑多线程（并行）支持。
排除 Worker 线程，JavaScript 几乎可以说是单线程。为了实现异步 I/O，Node.js 显然要通过 libuv 的多个线程（线程池）来实际调用系统调用，并在操作完成时通知 JavaScript 线程。

下面以 fs.open() 为例

/**
 * Asynchronously opens a file.
 * @param {string | Buffer | URL} path
 * @param {string | number} [flags]
 * @param {string | number} [mode]
 * @param {(err?: Error, fd?: number) => any} callback
 * @returns {void}
 */
function open(path, flags, mode, callback) {
    path = getValidatedPath(path);
    if (arguments.length < 3) {
        callback = flags;
        flags = "r";
        mode = 0o666;
    } else if (typeof mode === "function") {
        callback = mode;
        mode = 0o666;
    } else {
        mode = parseFileMode(mode, "mode", 0o666);
    }
    const flagsNumber = stringToFlags(flags);
    callback = makeCallback(callback); // 包装回调函数

    const req = new FSReqCallback(); // 创建请求
    req.oncomplete = callback; // 请求对象上附加回调函数
    // 将请求对象发送给 libuv
    binding.open(pathModule.toNamespacedPath(path), flagsNumber, mode, req);
}

fs.open() 函数最终通过 node_file.cc 调用 libuv 的 uv_fs_open() 方法

以 unix 系统为例，实现非阻塞 I/O 的背后可能是 read select poll epoll pselect kqueue evport 等等系统调用。

libuv 作为一个跨平台的 C 库，在 unix 下使用 epoll，在 BSD 下使用 kqueue，在 windows 下使用 IOCP，在 SunOS 下使用 event ports 实现。

libuv architecture

网络异步 I/O 可以通过对应系统调用实现，因此只需要单线程（事件循环线程）；而文件 I/O 则是通过线程池调用多个同步的系统调用模拟实现异步。

具体设计参见 libuv 文档

参见

https://stackoverflow.com/questions/25915634
https://zh.javascript.info/event-loop
https://v8.dev/blog/fast-async
https://limeii.github.io/2019/05/js-eventloop/
https://dev.to/lydiahallie/javascript-visualized-event-loop-3dif
https://dev.to/tdo95/javascript-event-loop-everything-you-need-to-know-explained-in-simple-terms-fg0
https://www.bbss.dev/posts/eventloop/
https://www.thisdot.co/blog/deep-dive-into-node-js-with-james-snell

←Back to home

This work is licensed under CC BY-NC-SA 4.0