20.1 事件循环优化 - 人人都会AI编程

Node.js 高并发的核心秘密在于事件循环：一个主线程用非阻塞的方式，在短短几毫秒内就能完成大量请求的调度与响应。事件循环一旦被长时间占用，整个服务的吞吐量就会断崖式下跌——新的请求无法被快速处理，已有请求的回调被延迟堆积，客户端感知到的就是超时、卡顿，甚至服务假死。因此，事件循环优化本质上就是确保主线程上的每一段代码都能在极短时间内完成，尽快将控制权交还给事件循环。

本章我们将从两个维度展开：先识别那些最容易让事件循环“喘不过气”的常见阻塞场景并给出替代方案，再深入探讨如何将不可避免的 CPU 密集型任务安全地拆分或转移，做到既完成任务又不影响响应。

20.1.1 避免阻塞事件循环的常见场景

任何在主线程上执行的同步代码，只要运行时间过长，都会阻塞事件循环。以下是实际项目中最容易踩坑的几种情形，以及对应的优化策略。

1. 大规模同步文件操作

典型错误做法：

// 阻塞事件循环！大文件会严重拖慢服务器
const data = fs.readFileSync('/path/to/large-file.csv');
processFile(data);

readFileSync 会完全阻塞当前线程，直到整个文件读取完毕。在并发场景下，所有请求都要排队等待这个同步 I/O 完成。即便是中等规模的日志文件（几十 MB），也会导致服务出现明显的卡顿。

优化策略：使用异步 API 或将文件处理改为流式。

// 异步版本：不阻塞
fs.readFile('/path/to/large-file.csv', (err, data) => {
  if (err) throw err;
  processFile(data);
});

// 流式处理：内存友好且不阻塞
const readStream = fs.createReadStream('/path/to/large-file.csv');
readStream.on('data', (chunk) => {
  // 逐块处理，不必等待全部数据
  processChunk(chunk);
});

2. 复杂正则表达式

某些正则表达式（尤其是包含回溯过深的模式）可以在毫秒甚至秒级内消耗 CPU，导致事件循环停滞。

// 高风险：redos 攻击或复杂匹配
const regex = /^(a+)+$/;
regex.test('aaaaaaaaaaaaaaaaaaaaaaaaaaaaab'); // 可能长时间运行

优化策略：

使用安全的、经过测试的正则表达式，避免嵌套量词。
对用户输入进行长度限制。
利用 re2 等库，它们使用更安全的算法，性能可预测。
将正则校验移到子进程或 Worker 中。

3. 海量 JSON 序列化/解析

JSON.stringify() 和 JSON.parse() 都是同步阻塞操作。当对象非常大时（例如包含数千个嵌套字段），这些操作会明显延迟事件循环。

// 危险的同步操作
const jsonStr = JSON.stringify(massiveObject);

优化策略：

避免在主线程上处理超大型 JSON。可以考虑流式 JSON 解析器（如 JSONStream）。
如果必须处理，使用 worker_threads 转移。
对 API 响应进行分页，避免一次性返回所有数据。

4. 无限循环或计算密集型算法

任何在主线程中长时间运行的算法，比如大量数字的排序、斐波那契数列计算、加密解密等，都会立即占满事件循环。

// 典型的阻塞代码
for (let i = 0; i < 1e9; i++) {
  // 复杂计算
}

优化策略：参考 20.1.2 节的拆分方案，或直接使用 Worker。

5. 同步的数据库查询/网络请求

虽然主流的数据库驱动大多提供异步 API，但某些情况下开发者可能顺手写出同步的网络请求调用（比如使用了同步的 HTTP 客户端）。这会彻底违背 Node.js 的非阻塞哲学，必须在代码审查阶段杜绝。

原则：永远不要在服务端代码中使用任何同步 I/O API，除非是在启动初始化阶段（如加载配置文件）。

6. 大量同步的文件系统遍历

fs.readdirSync 配合递归遍历庞大的目录树，也会长时间占满主线程。

优化方案：使用 fs.readdir 的异步版本，或利用 fast-glob 等模块，它们在内部也利用了流和异步模式。

20.1.2 CPU 密集任务拆分与异步化

有些计算任务本身是不可避免的，比如生成报表、图片处理、密码哈希等。Node.js 提供了一套将重计算“拆开”并“挪走”的方法，以避免它们破坏事件循环的响应能力。

方法一：任务分片（Task Partitioning）

将大型同步任务拆成多个小子任务，每个子任务处理一小部分数据，然后使用 setImmediate 或 process.nextTick 将后续子任务放入下一轮事件循环，让其他 I/O 有机会穿插执行。

function processLargeArray(items, batchSize = 100) {
  let index = 0;
  function nextBatch() {
    const end = Math.min(index + batchSize, items.length);
    for (; index < end; index++) {
      // 对每个 item 进行温和的计算
      heavyTransform(items[index]);
    }
    if (index < items.length) {
      // 将下一个批次的执行推迟，让事件循环喘息
      setImmediate(nextBatch);
    }
  }
  nextBatch();
}

选择 setImmediate 而非 process.nextTick 是有讲究的：setImmediate 会在事件循环的 check 阶段执行，给 I/O 回调留出处理窗口；process.nextTick 会在当前阶段结束后、下一阶段开始前立即执行，如果递归调用，会直接导致 I/O 饥饿。分片任务一般推荐 setImmediate。

方法二：使用 worker_threads 转移计算

Node.js 10.5+ 引入了 worker_threads 模块，可以创建真正的系统线程，每个线程拥有独立的 V8 实例和事件循环。将 CPU 密集计算丢给 Worker 后，主线程可以丝毫不受影响地继续处理 I/O。

// main.js
const { Worker } = require('worker_threads');

function runHeavyTask(data) {
  return new Promise((resolve, reject) => {
    const worker = new Worker('./heavy-worker.js', {
      workerData: data
    });
    worker.on('message', resolve);
    worker.on('error', reject);
    worker.on('exit', (code) => {
      if (code !== 0)
        reject(new Error(`Worker stopped with exit code ${code}`));
    });
  });
}

// 在需要时调用，不会阻塞主线程
runHeavyTask(someLargeData).then(result => {
  // 处理结果
});

// heavy-worker.js
const { parentPort, workerData } = require('worker_threads');

// 执行密集计算
const result = performHeavyComputation(workerData);
parentPort.postMessage(result);

Worker 之间还可以共享内存（SharedArrayBuffer），但线程安全需要开发者自己控制。对于绝大多数场景，消息传递已足够清晰和安全。

方法三：拆分为独立子进程

利用 child_process.fork() 也可以将计算任务放到新的 Node.js 进程里执行，达到与 Worker 类似的效果。区别在于子进程是完全独立的系统进程，拥有独立的内存空间，启动较慢，但隔离性更强。

选择策略

计算时间稳定在几毫秒内，且数据可分批处理：优先用任务分片，简单快捷。
计算耗时数百毫秒甚至秒级，且不希望影响主线程的任何请求：使用 worker_threads。
计算逻辑需要访问独立的文件系统或环境变量，或必须绝对进程隔离：使用 子进程。

20.1.3 实战案例：报表生成接口的优化

以一个常见的后台系统需求为例：用户请求下载一份 CSV 报表，后端需从数据库查询 10 万条记录，进行格式化，最后生成文件。如果直接在请求处理函数中完成所有步骤，这个请求会独占主线程数秒甚至更久，期间整个服务响应变慢。

优化步骤：

数据库查询使用异步 API，利用 cursor 或 stream 逐条获取，而不是一次性 findAll。
格式化与拼接字符串任务转到 Worker 线程中处理，主线程只负责接收最终结果。
Worker 生成完 CSV 内容后，通过消息发送给主线程，主线程再用异步方法写入文件（或直接在 Worker 中写文件）。
如果报表请求频繁，可引入任务队列（Bull、Agenda）将生成任务异步化，客户端通过轮询或 WebSocket 获取完成通知。

这样处理后，报表请求对主线程的阻塞时间几乎为零，服务在生成报表的同时依然能快速响应其他正常请求。

20.1.4 监控与预警

即使做了上述优化，线上环境仍可能出现意料之外的阻塞。我们需要监控事件循环的滞后程度来及时发现问题：

利用 process.hrtime() 或 event-loop-lag 包，测量事件循环的“滴答”间隔，如果超出阈值（如 100ms）便记录告警。
应用性能监控（APM）工具，如 New Relic、Datadog、Elastic APM，均提供了事件循环延迟的指标看板。
设置告警规则：当事件循环平均延迟持续超过 50ms 时，触发告警，提醒开发人员排查是否有代码异常或资源瓶颈。

原则很简单：让每一行在主线程上执行的代码都保持短小、异步化。 做到这一点，Node.js 的事件循环就能持续低延迟、高吞吐地运转，支撑起庞大的并发业务。