1. Node.js 运行时架构与事件循环机制

说实话，很多Node.js开发者写了几年代码，却不太清楚代码到底是怎么跑起来的。我刚开始接触Node.js时也是这样，直到有一次线上服务频繁超时，排查了三天才发现是事件循环被阻塞了。那次之后，我下定决心把底层机制啃了一遍。

今天我们就来聊聊Node.js的运行时架构。说白了，就是搞清楚三件事：libuv、V8、事件循环。它们是怎么配合的？又怎么影响你的性能？

1.1 Node.js 的三大核心组件

Node.js不是一门语言，它是一个运行时环境。它的骨架由三部分组成：

  • V8 引擎：Google开发的JavaScript引擎。负责把JS代码编译成机器码，然后执行。嗯，V8只管执行，不管别的。
  • libuv：这才是Node.js的"幕后英雄"。它负责处理文件I/O、网络请求、定时器、子进程等异步操作。说白了，没有libuv，Node.js就是个单线程的死循环。
  • Node.js 绑定层：把V8和libuv粘合在一起的胶水代码。比如fs.readFile这个API，就是通过绑定层把JS调用转成libuv的任务。

核心理解：V8负责"算"，libuv负责"等"。两者通过事件循环协作。

1.2 事件循环的六个阶段

事件循环是Node.js的"心脏"。它按照固定的顺序，轮询检查各个阶段是否有任务需要处理。我习惯把它想象成一个流水线，每个阶段就是一个工位。

完整的事件循环包含以下阶段（按顺序执行）：

阶段 名称 主要任务 典型API
1 timers 执行到期的定时器回调 setTimeout, setInterval
2 pending callbacks 执行延迟到下一轮的I/O回调 某些系统错误回调
3 idle, prepare 内部使用，开发者接触不到 libuv内部
4 poll 获取新的I/O事件，执行I/O回调 fs.readFile, 网络请求
5 check 执行setImmediate回调 setImmediate
6 close callbacks 执行关闭事件的回调 socket.on('close')

为什么会设计这么多阶段？你想想看，不同类型的任务优先级不一样。定时器需要准时触发，I/O回调可以稍微等一等，而setImmediate则希望尽快执行。分阶段管理，才能保证公平性和响应速度。

1.3 poll 阶段：最关键的"等待室"

poll阶段是整个事件循环中最特殊的一个。它做的事情很简单：等。

具体来说，poll阶段会做两件事：

  1. 检查是否有新的I/O事件到达（比如文件读取完成、网络数据到来）
  2. 如果有，执行对应的回调函数

但这里有个关键点：poll阶段会阻塞等待。如果没有I/O事件，也没有定时器到期，它就会一直等下去。我曾经在项目中遇到过一个问题：一个HTTP服务在低负载时响应很快，但高并发下突然变慢。排查后发现，是因为某个中间件里写了个while(true)的空循环，把事件循环卡死在poll阶段了。

避坑指南：千万不要在回调函数里写同步的死循环或大量CPU计算。我曾经见过有人用for循环处理10万条数据，直接把事件循环阻塞了5秒钟。所有其他请求都得排队等着，那叫一个酸爽。

1.4 timers 与 check 阶段的微妙关系

很多初学者搞不清setTimeout(fn, 0)和setImmediate的区别。我直接说结论：

  • setTimeout(fn, 0)：把回调放到timers阶段，但实际最小延迟是1ms（浏览器和Node.js都是）
  • setImmediate：把回调放到check阶段，在poll阶段之后立即执行

看个例子就明白了：

setTimeout(() => {
  console.log('timeout');
}, 0);

setImmediate(() => {
  console.log('immediate');
});

// 输出结果：不一定！
// 大部分情况下是 immediate 先输出
// 但如果系统负载高，timeout 可能先输出

为什么会这样？因为setTimeout(fn, 0)虽然设了0毫秒，但libuv内部会把它转成1ms。如果事件循环进入timers阶段时，这1ms还没到，那就跳过timers阶段，先执行poll和check。等下一轮循环再回来处理这个定时器。

个人经验：如果你想让一个回调"尽快"执行，用setImmediate比setTimeout(fn, 0)更可靠。我在写高精度定时任务时，一般会用setImmediate配合process.nextTick来微调执行顺序。

1.5 process.nextTick 与微任务

这里有个容易踩的坑。process.nextTick并不是事件循环的一个阶段。它属于微任务，在每个阶段切换时都会检查并执行。

执行优先级是这样的：

  1. 当前阶段的所有回调执行完毕
  2. 执行所有process.nextTick回调
  3. 执行所有Promise的.then回调（微任务）
  4. 进入下一个阶段

我建议你记住一句话：nextTick 比 Promise 还快。看代码：

process.nextTick(() => {
  console.log('nextTick');
});

Promise.resolve().then(() => {
  console.log('promise');
});

console.log('sync');

// 输出顺序：
// sync
// nextTick
// promise

注意：滥用process.nextTick会导致I/O饥饿。如果你在nextTick里递归调用nextTick，事件循环永远进不了poll阶段，其他I/O请求就永远得不到处理。我曾经在一个日志库中看到这种写法，结果服务启动后所有HTTP请求都超时了。

1.6 事件循环如何影响性能

理解了事件循环的机制，性能优化就有了方向。我总结了三个核心原则：

  • 不要阻塞事件循环：任何同步的CPU密集型操作（JSON解析、加密、大数据排序）都会阻塞所有阶段。解决方案是用worker_threads或拆分任务。
  • 合理分配任务到不同阶段：定时任务用setTimeout，I/O密集型用poll阶段，需要尽快执行的用setImmediate。
  • 控制微任务的数量：process.nextTick和Promise虽然快，但太多会拖慢阶段切换。

举个实际例子。我之前优化过一个API网关，它需要对每个请求做JWT验证。JWT验证涉及Base64解码和签名校验，是CPU密集型的。一开始直接在请求处理函数里同步验证，结果QPS一上去，延迟就飙升。

优化方案是把JWT验证放到worker_threads里执行，主线程只负责接收请求和返回响应。改造后，同样的机器配置，QPS提升了3倍。

一句话总结：Node.js性能优化的本质，就是让事件循环"不等待"。V8只管算，libuv只管等，两者别互相拖后腿。

1.7 本章小结

嗯，内容不少，我们捋一下重点：

  • Node.js运行时 = V8 + libuv + 绑定层
  • 事件循环有6个阶段，按固定顺序轮询
  • poll阶段是"等待室"，会阻塞等待I/O事件
  • setImmediate比setTimeout(fn, 0)更可靠
  • process.nextTick是微任务，优先级最高，但别滥用
  • 性能优化的核心：别阻塞事件循环

下一章我们会深入V8的内存管理和垃圾回收机制。到时候我会分享一个真实的内存泄漏案例——那是我在某个金融项目中踩过的坑，差点导致生产环境OOM。敬请期待。

← 上一章 📖 返回目录 下一章 →