Node.js 是单线程的吗？它怎么处理高并发？

详细解析#

"单线程"指的是什么#

• 我们写的 JS 代码都在主线程上运行，同一时刻只执行一段代码，不用考虑锁和线程安全
• 进程里还有其他线程：libuv 的线程池，V8 用来做垃圾回收、编译优化的后台线程等
• 主线程按事件循环工作：取出已经就绪的事件，执行对应的回调，再取下一个

高并发靠非阻塞 I/O#

主线程（执行 JS）
  │ 发起 I/O：登记回调后立刻返回，继续处理别的请求
  ├──> 网络 I/O（TCP、UDP、管道）────> 操作系统多路复用：epoll / kqueue / IOCP
  └──> fs、dns.lookup、crypto、zlib ──> libuv 线程池（默认 4 个线程）
                    │ 完成后把事件交回事件循环
主线程取出事件，执行回调

以一个查数据库的请求为例：

1. 请求到达，主线程执行路由回调，向数据库发出查询（网络 I/O）
2. 这个 socket 交给 epoll 监听，主线程立刻返回，去处理其他请求
3. 数据库返回数据后，epoll 通知 libuv，事件循环在 poll 阶段执行回调，生成响应

传统的"一个连接一个线程"模型，连接越多线程越多，每个线程都要占用栈内存，线程切换也有开销。Node.js 用一个线程加事件通知服务大量连接，在以等待 I/O 为主的场景下资源占用更少。

哪些操作走线程池#

操作系统对网络 I/O 有成熟的异步通知机制，但文件操作在各个平台上缺少统一、可靠的异步接口，getaddrinfo 这类系统调用本身也是同步的。libuv 就在线程池里调用这些同步接口，完成后再通知主线程：

线程池默认 4 个线程，可以用环境变量 UV_THREADPOOL_SIZE 调整，上限 1024。要在启动时设置，比如 UV_THREADPOOL_SIZE=8 node app.js；在代码里改 process.env 不保证生效，比如线程池可能在用户代码运行前就已经创建。

代码示例#

同时发起 8 个 pbkdf2 计算，观察线程池的排队：

// pool.mjs
import { pbkdf2 } from 'node:crypto'

const start = performance.now()
for (let i = 1; i <= 8; i++) {
  pbkdf2('secret', 'salt', 300_000, 64, 'sha512', () => {
    console.log(`任务 ${i} 完成：${Math.round(performance.now() - start)}ms`)
  })
}

默认 4 个线程时，任务分两批完成，第二批的耗时大约是第一批的两倍；在核数足够的机器上用 UV_THREADPOOL_SIZE=8 node pool.mjs 运行，8 个任务几乎同时完成。完成的先后顺序不固定。

CPU 密集的同步代码会让所有请求一起等待：

// block.mjs
import http from 'node:http'

http.createServer((req, res) => {
  if (req.url === '/slow') {
    const end = Date.now() + 5000
    while (Date.now() < end) {} // 模拟 5 秒的同步计算
  }
  res.end('ok\n')
}).listen(3000)

先请求 /slow 再请求 /，后者也要等将近 5 秒：主线程一直被占着，事件循环处理不了新的请求。这类计算应该放进 Worker 线程（见 Node.js 怎么利用多核），或者拆成小块、用 setImmediate 分批执行，中间把主线程让出来。

面试官可能追问#

import { monitorEventLoopDelay } from 'node:perf_hooks'

const histogram = monitorEventLoopDelay({ resolution: 20 })
histogram.enable()
setInterval(() => {
  // 单位是纳秒，换算成毫秒
  console.log('p99:', (histogram.percentile(99) / 1e6).toFixed(1), 'ms', 'max:', (histogram.max / 1e6).toFixed(1), 'ms')
  histogram.reset()
}, 10_000).unref()

易错点#

• "Node.js 是单线程的"只说对了一半：单线程的是 JS 的执行，I/O 由操作系统和线程池并发完成
• 网络 I/O 不走线程池，调大 UV_THREADPOOL_SIZE 对纯网络请求没有帮助（dns.lookup 解析除外）
• 异步 API 只是不用等待 I/O，回调里的计算照样占用主线程。fs.readFileSync、对很大的字符串做 JSON.parse、会灾难性回溯的正则，都会阻塞事件循环