Node.js 依赖 Chrome V8 引擎执行 JavaScript，默认情况下所有用户代码都跑在主线程中。事件循环让异步 I/O 不阻塞执行，但 CPU 密集操作却会把整个进程拖住。比如一个 5000 万次循环的数组处理，主线程需要连续计算，此时任何新的网络请求都无法及时响应。Worker Threads 从 Node.js 10.5.0 开始作为实验特性引入，到 12 版本后趋于稳定，它允许开发者创建真正独立的工作线程，每个线程有自己的执行栈、事件循环和 V8 隔离环境。通过将计算任务移出主线程，可以有效避免接口延迟、连接超时等问题。

与 child_process 最大的区别在于，Worker Threads 共享同一个进程地址空间，线程间可以通过消息端口和共享内存进行更轻量的数据交换。下面先来看线程的创建方式与基础结构。

一、Worker Threads 的创建与基础结构

Worker Threads 模块可以从 worker_threads 中导入，核心对象包括 Worker、isMainThread、parentPort 等。主线程通过 new Worker(filename) 创建子线程，工作线程内部通过 parentPort.postMessage() 与主线程通信，通过 workerData 接收初始化参数。下面是一个最小可运行示例：

const { Worker, isMainThread, parentPort, workerData } = require('worker_threads');
if (isMainThread) {
  // 主线程分支
  const worker = new Worker(__filename, {
    workerData: { start: 1, end: 100 }
  });
  worker.on('message', (result) => {
    console.log('收到工作线程结果：', result);
  });
  worker.on('error', (err) => {
    console.error('工作线程出错：', err);
  });
} else {
  // 工作线程分支
  const { start, end } = workerData;
  let sum = 0;
  for (let i = start; i <= end; i++) {
    sum += i;
  }
  parentPort.postMessage(sum);
}

这里使用同一个文件，通过 isMainThread 判断当前执行环境。主线程在创建 Worker 时传入 workerData，子线程读取该数据并完成求和，最后把结果发送回主线程。需要特别注意的是，workerData 会被结构化克隆，因此只能传递普通对象、数组、基本类型、ArrayBuffer 等可序列化数据，不能传递函数、类、Symbol 或包含循环引用的结构。

此外，每个 Worker 线程启动时都会创建独立的 V8 实例和事件循环，这带来一定的内存与启动成本。一个空的 Worker 大约占用 10 MB 左右内存，如果同时创建上百个线程，仅启动开销就会消耗大量资源。因此在实际项目中，通常会预先创建固定数量的工作线程，以线程池的方式复用它们，而不是每来一个任务就临时创建。

二、线程间通信与数据共享策略

Worker Threads 默认使用 postMessage 传递消息，底层采用结构化克隆算法。这意味着对象会被完整复制一份，两个线程不共享引用。对于小规模控制消息来说完全够用，但当需要频繁传递大数组或大数据块时，克隆和序列化会带来显著 CPU 成本。为了降低复制开销，可以使用 transferList 转移对象所有权，转移后原线程将无法再访问该对象。常见的可转移对象包括 ArrayBuffer、MessagePort、FileHandle 等。

const { Worker, isMainThread, parentPort } = require('worker_threads');
if (isMainThread) {
  const buffer = new ArrayBuffer(1024 * 1024 * 16); // 16 MB
  const worker = new Worker(__filename);
  worker.postMessage({ buffer }, [buffer]);
  console.log('主线程 buffer 长度：', buffer.byteLength); // 转移后为 0
} else {
  parentPort.on('message', ({ buffer }) => {
    console.log('工作线程收到 buffer 长度：', buffer.byteLength);
  });
}

上面的代码中，主线程把 buffer 放进 transferList，转移后主线程中的 buffer.byteLength 变为 0，所有权已经交给工作线程。这种方式避免了 16 MB 数据的复制操作，适合大块二进制数据。但缺陷是一旦转移，原线程就无法继续使用，因此需要根据生命周期做判断。

如果希望多线程同时读写同一块内存，可以使用 SharedArrayBuffer 配合 Atomics。共享内存不会被克隆，多个线程可以直接操作同一块地址空间，性能最高，但也容易产生数据竞争。比如两个线程同时执行 sharedArray[0]++，可能结果小于预期。此时需要 Atomics.add()、Atomics.wait() 等原子操作来保证一致性。共享内存适合图像像素统计、矩阵分块计算等场景，每个线程只写自己负责的区间，读取公共数据时使用原子操作。

三、实战：封装一个通用线程池执行 CPU 密集任务

假设我们需要对一批大数组进行排序，或者计算多个独立任务的执行时间。直接在主线程逐任务执行会导致阻塞。一个较优方案是创建与 CPU 核心数相当的 Worker，并把任务分发到空闲线程。下面给出一个简化版线程池，它维护固定数量的 Worker，每个 Worker 复用同一个监听器，主线程通过 Promise 管理任务状态。

const { Worker } = require('worker_threads');
class ThreadPool {
  constructor(workerPath, size = 4) {
    this.workerPath = workerPath;
    this.size = size;
    this.workers = [];
    this.queue = [];
    this.activeTasks = new Map();
    this.nextId = 0;
    for (let i = 0; i < size; i++) {
      const worker = new Worker(workerPath);
      worker.on('message', (message) => this.handleMessage(worker, message));
      worker.on('error', (err) => this.handleError(worker, err));
      this.workers.push(worker);
    }
  }
  run(data) {
    const id = this.nextId++;
    return new Promise((resolve, reject) => {
      const task = { id, data, resolve, reject };
      const idleWorker = this.workers.find((w) => !this.activeTasks.has(w.threadId));
      if (idleWorker) {
        this.activeTasks.set(idleWorker.threadId, task);
        idleWorker.postMessage({ id, data });
      } else {
        this.queue.push(task);
      }
    });
  }
  handleMessage(worker, message) {
    const task = this.activeTasks.get(worker.threadId);
    if (task) {
      this.activeTasks.delete(worker.threadId);
      task.resolve(message.result);
      this.tryNext(worker);
    }
  }
  handleError(worker, err) {
    const task = this.activeTasks.get(worker.threadId);
    if (task) {
      this.activeTasks.delete(worker.threadId);
      task.reject(err);
      this.tryNext(worker);
    }
  }
  tryNext(worker) {
    if (this.queue.length > 0) {
      const nextTask = this.queue.shift();
      this.activeTasks.set(worker.threadId, nextTask);
      worker.postMessage({ id: nextTask.id, data: nextTask.data });
    }
  }
}
module.exports = ThreadPool;

这段代码的核心逻辑是把每个任务包装成 Promise，当有空闲 Worker 时直接派发；否则进入队列等待。每个 Worker 完成消息后，主线程根据 threadId 找到对应任务并 resolve，同时尝试从队列取出下一个任务。这样避免了频繁创建销毁线程的开销。工作线程对应的脚本可以写成下面这样：

const { parentPort } = require('worker_threads');
function heavyCompute(data) {
  let result = 0;
  for (let i = 0; i < data.count; i++) {
    result += Math.sqrt(i);
  }
  return result;
}
parentPort.on('message', ({ id, data }) => {
  const result = heavyCompute(data);
  parentPort.postMessage({ id, result });
});

使用时只需要创建一次线程池，然后批量调用 run。线程池大小一般设置为 os.cpus().length - 1 或等于 CPU 核心数，避免超过物理核心导致频繁上下文切换。如果任务本身很小，线程池的通信和调度开销反而会超过单线程执行时间，此时应保持串行或使用其他异步拆分方式。

四、Worker Threads 的性能边界与选型建议

Worker Threads 并不是解决所有性能问题的银弹。它的主要优势是并行执行 CPU 密集任务，对于 I/O 密集型任务，Node.js 的事件循环和异步 API 已经足够高效。因为文件读取、数据库查询、HTTP 请求等操作在底层都交给了 libuv 线程池或操作系统，主线程不需要等待，此时再创建 Worker 并不会带来明显收益，反而增加内存和通信开销。

多线程编程的复杂度也更高。共享内存方案需要开发者自己处理数据竞争、锁、线程同步等问题；消息传递方案则要考虑结构化克隆成本与对象生命周期。一般来说，单次计算耗时超过 50~100 毫秒，且任务之间相互独立时，才适合考虑 Worker Threads。如果任务间有强依赖，或者需要频繁读写共享状态，使用多线程可能比单线程更难维护且未必更快。

与 cluster 模块相比，cluster 主要解决多核利用问题，它通过 fork 多个进程来扩展 HTTP 服务，每个进程独立占据内存，适合 Web 服务水平扩展。Worker Threads 则在同一进程内共享内存空间，适合计算型任务。还有一些项目会综合使用两者：用 cluster 起多个进程，每个进程内部再用 Worker Threads 做并行计算。具体选型需要根据任务类型、数据规模、内存限制和团队维护能力综合判断。