简介
Node.js 作为 JavaScript 后端运行环境,其核心优势在于高并发处理能力和非阻塞 I/O 模型。
特点:
- 高并发处理:单线程事件循环高效处理大量并发连接
- I/O 密集型任务:非阻塞 I/O 模型避免线程切换开销,不适合 CPU 密集型任务(如视频编码)
- 前后端技术统一:JavaScript 全栈开发
注意:
Node.js 不是多线程的,主线程是单线程,但通过线程池处理部分操作
使用场景
- Web 服务器(如 REST API)
- 实时应用(如聊天、协作工具)
- 微服务架构中的网关 / 代理服务
- 数据管道和流处理
分层架构
- 底层系统
- 操作系统:Linux、Windows、macOS 等
- 系统调用:文件操作、网络通信等底层 API
- C/C++ 核心库
- V8 引擎:Google 开发的 JavaScript 执行引擎,负责编译和执行 JS 代码
- libuv:Node.js 自主开发的跨平台异步 I/O 库,封装操作系统底层 API
- OpenSSL:提供加密和安全通信功能
- zlib:压缩 / 解压缩数据
- JavaScript 核心模块
- 如 fs(文件系统)、net(网络)、http(HTTP 服务器)等,通过 Node.js 绑定层调用底层 C/C++ 库
- 用户应用层
开发者编写的 Node.js 应用代码
事件循环
Node.js 的事件循环(Event Loop)是其异步 I/O 的核心机制,由 Libuv 库实现。它将事件循环分为 7 个主要阶段,每个阶段按特定顺序执行不同类型的回调任务。以下是各阶段的详细说明:
- timers 阶段(定时器阶段)
- pending callbacks 阶段(待定回调阶段)
- idle, prepare 阶段(内部准备阶段)
- poll 阶段(轮询阶段)
- check 阶段(检查阶段)
- close callbacks 阶段(关闭回调阶段)
- nextTick 与 microtasks(穿插执行,不属于主阶段)
setTimeout 与 setImmediate 的执行顺序
在 Node.js 中,setTimeout 和 setImmediate 的执行顺序取决于它们的调用位置和事件循环的状态。这是一个常见的面试考点,也是理解 Node.js 异步机制的关键。
核心区别
- setTimeout(callback, 0)
- 理论上立即执行回调,但实际延迟 ≥ 1ms(受系统调度影响)。
- 回调在事件循环的 Timer 阶段执行。
- setImmediate()
- 设计用于在当前轮询阶段结束后立即执行回调。
- 回调在事件循环的 Check 阶段执行。
执行顺序
- 在主模块中调用的时候
当两者在主模块中调用的时候,执行顺序不固定,取决于 JavaScript 引擎的初始化速度和系统负载。
// 示例1:主模块中直接调用
setTimeout(() => {
console.log('定时器回调');
}, 0);
setImmediate(() => {
console.log('setImmediate 回调');
});
// 可能的输出:
// 1. 定时器回调 → setImmediate 回调(常见情况)
// 2. setImmediate 回调 → 定时器回调(极少情况,系统负载高时可能发生)
原因
- setTimeout(…, 0) 实际延迟 ≥ 1ms,如果系统繁忙,可能超过 1ms。
- 如果延迟超过 1ms,事件循环进入 Check 阶段时,定时器尚未触发,导致 setImmediate 先执行。
- 在异步 I/O 回调中调用
当两者在异步 I/O 回调(如 fs.readFile)中调用时,setImmediate 总是先于 setTimeout 执行。
// 示例2:在I/O回调中调用
const fs = require('fs');
fs.readFile(__filename, () => {
setTimeout(() => {
console.log('定时器回调');
}, 0);
setImmediate(() => {
console.log('setImmediate 回调');
});
});
// 输出顺序固定为:
// setImmediate 回调 → 定时器回调
原因
- 异步 I/O 回调在Poll 阶段执行。
- 执行完毕后,事件循环进入Check 阶段,执行 setImmediate 的回调。
- 下一轮循环的 Timer 阶段才会执行 setTimeout 的回调。