Day 5 - worker_threads:分店太贵,能不能在店里加个操作台?

🧾 接上回:分店开起来了,但账单有点贵

Day 4 我们学会了开分店:cluster 起 4 个 worker 进程,把 4 颗 CPU 核都用上,一家店崩了其他三家照常营业。听起来完美。

但月底一算账,发现三件事:

翻译成技术语言:

所以问题变成:有没有一种办法,不开新店,而是在同一家店里加一个操作台?共用同一个冰箱,不用复印菜谱,开一个只要几十毫秒。

有。它叫 worker_threads。

📇 概念卡 #1:worker_threads —— 店里的第二个操作台

Node 里的 worker_threads,和你想的不太一样

很多人第一次听到"Node 有多线程了",以为终于可以像 Java 那样几个线程一起跑同一段 JS。不是的。这里有一个必须搞清楚的真相:

那它到底省了什么?

看最后两行:worker_threads 不是 cluster 的升级版,是它的另一个方向。省了钱和搬运成本,代价是丢了隔离性。这就是今天要建立的判断力。

最小可运行例子

// main.ts —— 主线程
import { Worker } from "node:worker_threads";

const worker = new Worker(new URL("./worker.ts", import.meta.url), {
  workerData: { n: 40 },          // 开台时递进去的初始材料(拷贝一份)
});

worker.on("message", (result) => {  // 操作台做完了,喊一声
  console.log("结果:", result);
  worker.terminate();               // 用完关火,不然进程不退出
});
worker.on("error", (err) => console.error("worker 出错:", err));

// worker.ts —— 操作台
import { parentPort, workerData } from "node:worker_threads";

function fib(n: number): number {
  return n < 2 ? n : fib(n - 1) + fib(n - 2);
}

parentPort!.postMessage(fib(workerData.n));  // 做完装盘递回去

Node 24 小福利:worker 文件可以直接写 .ts,不用先编译。Node 会自己剥掉类型。今天的习题就是这么跑的。

🔀 三种传菜方式:拷贝 / 转移 / 共享

这一节是 worker_threads 里最容易被跳过、但面试最爱问的地方。两个线程之间传数据,有三种方式,性能差几百倍。

方式一:拷贝(structured clone)—— 默认行为

worker.postMessage(bigArray);   // 默认:完整复印一份

传 200 MB 就真的复制 200 MB。安全,但慢。大多数场景够用,因为你通常只传一个几 KB 的参数。

方式二:转移(transfer)—— 零拷贝,但原件作废

const buf = new ArrayBuffer(200 * 1024 * 1024);
worker.postMessage(buf, [buf]);   // 第二个参数:转移清单
// 这行之后,主线程里的 buf.byteLength === 0,它已经不属于你了

技术上叫"所有权转移"。内存还在原地没动,只是换了个主人。只有 ArrayBuffer 这类原始内存才能转移,普通对象不行。

方式三:共享(SharedArrayBuffer)—— 真正的同一块内存

const shared = new SharedArrayBuffer(1024);
const view = new Int32Array(shared);
worker.postMessage(shared);      // 不需要转移清单,双方都能用

// 主线程和 worker 都在操作同一块内存
Atomics.add(view, 0, 1);         // 安全地加 1
Atomics.load(view, 0);           // 安全地读

⚖️ 今天最重要的一节:什么时候该用,什么时候别用

前面都是"怎么用"。这一节是"该不该用"。面试问 worker_threads,九成是在问这个。

先记住一条铁律

决策表:照着查就行

💣 三个坑:创建成本、一请求一 worker、忘了关火

坑 1:以为 worker 是免费的

开一个 worker 要 10–40 ms,还要占 5–10 MB。如果你的任务只要 5 ms,开 worker 让它慢了 5 倍。

判断方法 先测。任务耗时至少要是"开台成本"的 10 倍以上,才值得开。

坑 2:每来一个请求就开一个 worker(最常见的生产事故)

// ❌ 千万别这么写
app.post("/pdf", async (req, res) => {
  const worker = new Worker("./pdf-worker.ts");   // 每个请求开一个
  // 100 个请求同时进来 = 100 个线程 = 内存爆炸 + 疯狂上下文切换
});

正确做法:worker pool。启动时开固定几个(通常等于 CPU 核数),排队复用。这和数据库连接池是同一个思想——Week 5 学连接池时你会发现是同一套话术。

// ✅ 提前开好,重复用
const pool = new WorkerPool("./pdf-worker.ts", os.availableParallelism());
app.post("/pdf", async (req, res) => {
  const pdf = await pool.run(req.body);   // 排队,轮到你就有台子用
  res.send(pdf);
});

今天的习题 3 就是手写一个最小 worker pool。

坑 3:忘了 terminate,进程不退出

只要还有活着的 worker,Node 进程就不会退出。脚本跑完卡住不动,九成是这个原因。

worker.on("message", (r) => {
  console.log(r);
  worker.terminate();      // ← 用完关火
});

长期运行的服务里则相反:worker pool 里的 worker 应该一直活着,别每次关。

🌍 跨语言对照:这套取舍在哪儿都一样

今天学的不是"Node 的 worker_threads API",是"共享内存并发"这个模型的代价与收益。换任何语言,这套判断都成立。

👉 学完记得去 roadmap.md 顶部的对照表,在"运行时与并发模型"那一行补一句你自己的话。

🛠️ 今日习题(约 100 min)

三道题,代码全部写在 src/05-worker-threads/。每道题都要跑出数字,不要只看代码。骨架已经建好,你只需要补关键部分。

✅ 总结与自测

今天带走的 5 句话

1. worker_threads 不是 cluster 的升级版,是另一个方向。它省了内存和搬运成本(线程共享进程底座),代价是丢了进程隔离——一个 worker 把内存吃爆,整个进程一起完蛋。
2. Node 的"多线程"不共享 JS 变量。每个 worker 有自己的 V8 isolate、自己的 event loop、自己的堆。唯一真共享的是 SharedArrayBuffer。
3. 传数据有三档:拷贝(默认,安全但和数据量成正比)、转移(零拷贝,原件作废)、共享(不用传,但要 Atomics 保证正确)。选错这一档,性能差几百倍。
4. 铁律:worker 解决 CPU 问题,不解决 I/O 问题。而且任务耗时要远大于开台成本(10–40 ms),否则开 worker 是负优化。
5. 高频任务一定要用 pool,不能一请求一 worker。"提前开好、排队复用"和数据库连接池是同一个思想,Week 5 会再见到它。

自测清单(能打勾才算今天过关)

• 能说出 worker_threads 和 cluster 的三个区别(启动成本、内存、崩溃影响),并说明各自适用场景
• 能解释"每个 worker 有独立 V8 isolate"这句话的实际后果:主线程的变量 worker 改不到
• 能说清拷贝 / 转移 / 共享三种传数据方式的差别,以及各自该用在什么地方
• 能讲清什么是竞态条件(race condition),并用"两人同时开冰箱"解释 Atomics 在防什么
• 能背出决策表至少 5 行,面对"这个功能卡住了要不要开 worker"能当场判断
• 能说出"一请求一 worker"为什么是生产事故,以及 worker pool 怎么解决
• 能用跨语言视角说明:为什么 Java/C#/Go 是"默认共享"的多数派,而 Node 和 Python 各自是不同方向的异类