JavaScript事件循环与异步机制

February 26, 2024

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

异步任务

异步任务在事件循环中调度执行。ECMA262 规范并未完全指定如何调度异步任务（规范称之为 job），与运行时相关（host-defined）。

因此，显然 setTimeout queueMicrotask 都是运行时 API，规范中并未定义

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

规定：

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

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

HTML 规范中称之为任务（task），这也是我们常用的说法。
HTML 规范中定义了如何调度异步任务。根据 HTML 规范，事件循环中可以有一个或多个任务队列。（微任务队列不是任务队列）

事件循环

除了规范定义的：

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

运行时内部实现任务队列，往往分为：

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

任务既然要被执行，那么就显然是函数
一旦调用栈为空，事件循环从任务队列中取出任务来执行
（往往是先微任务再宏任务）

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

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

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

浏览器

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

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

现代浏览器遵循 HTML 规范

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

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>

var outer = document.querySelector(".outer");
var 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://www.builder.io/blog/visual-guide-to-nodejs-event-loop

Node.js 的事件循环中有：

4 个任务队列

计时器队列（严格来说是一个最小堆），其中包含与 setTimeout 和 setInterval 关联的回调。
I/O 队列，其中包含与所有异步方法关联的回调，比如与 fs 和 http 模块关联的方法。
检查队列，其中包含与 setImmediate 函数关联的回调，这是特定于 Node 的。
关闭队列，其中包含与异步任务的 close 事件关联的回调。

2 个微任务队列

nextTick 队列，其中包含与 process.nextTick 函数关联的回调。
Promise 队列，其中包含与 JavaScript 原生 Promise 关联的回调。

注意，计时器、I/O、检查和关闭队列都是 libuv 的一部分。然而，这两个微任务队列不是 libuv 的一部分。
尽管如此，它们仍然是 Node 运行时的一部分，并且在回调的执行顺序中扮演着重要的角色。

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

目前 Node.js 中存在 Callback 和 Promise 两种 API，显然 Callback 版本的性能会高一些。
以下以 Callback API 为例。

在 Node.js 中每个队列称为一个阶段。当事件循环进入给定阶段时，将执行特定于该阶段的任何操作，然后执行该阶段队列中的回调，直到队列耗尽或当最大回调数已执行。
当队列耗尽或达到回调限制时，事件循环将进入下一阶段，依此类推。
根据上文，有 4 个任务队列，上文实际上是一种省略的说法，实际上是 6 个。因此有 6 个阶段：

计时器 (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]) 以及 v8 暴露的 queueMicrotask(callback)

process.nextTick 的 next tick 即事件循环继续之前。此 API 由 Node.js 控制，但实践中与 queueMicrotask 差异很小。
具体信息，Node.js 文档中已经很详细说明了。

当我们实现一个函数执行回调时，保证回调函数异步执行往往很重要。
不过在实践中，使用 Promise API 往往更加方便了。

function definitelyAsync(arg, cb) {
    if (arg) {
        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

←Back to home

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