worker_threads

worker_threads descarrega JavaScript com uso intensivo de CPU para threads paralelos sem iniciar um novo processo do sistema operacional - use workerData, passagem de mensagens e, opcionalmente, SharedArrayBuffer para estado compartilhado.

Receita

import { Worker } from 'node:worker_threads';
import { fileURLToPath } from 'node:url';
 
const worker = new Worker(fileURLToPath(new URL('./hash-worker.js', import.meta.url)), {
  workerData: { input: 'payload' },
});
 
worker.on('message', (result) => console.log(result));

Quando usar isso:

• Rounds bcrypt/scrypt, redimensionamento de imagem, geração de PDF em JS
• Transformação JSON grande ou análise CSV bloqueando o loop de eventos
• Mapeamento paralelo sobre itens de trabalho de CPU com tamanho de pool fixo
• Operações criptográficas que não delegam suficientemente ao pool de threads crypto

Exemplo de Trabalho

// main.ts
import { Worker } from 'node:worker_threads';
import { cpus } from 'node:os';
import { fileURLToPath } from 'node:url';
 
const poolSize = Math.min(4, cpus().length);
const workers: Worker[] = [];
const queue: Array<{ data: number[]; resolve: (v: number) => void }> = [];
 
for (let i = 0; i < poolSize; i++) {
  const w = new Worker(fileURLToPath(new URL('./sum-worker.js', import.meta.url)));
  w.on('message', (sum: number) => {
    const job = queue.shift();
    job?.resolve(sum);
    w.postMessage(job?.data ?? []);
  });
  workers.push(w);
}
 
export function sumInWorker(nums: number[]): Promise<number> {
  return new Promise((resolve) => {
    queue.push({ data: nums, resolve });
    const idle = workers.find((w) => !w.threadId) ?? workers[0];
    idle.postMessage(nums);
  });
}

// sum-worker.js
import { parentPort, workerData } from 'node:worker_threads';
 
parentPort?.on('message', (nums: number[]) => {
  const sum = nums.reduce((a, b) => a + b, 0);
  parentPort?.postMessage(sum);
});
 
if (workerData) {
  parentPort?.postMessage('ready');
}

O que isso demonstra:

• Tamanho do pool limitado - não crie workers ilimitados por solicitação
• postMessage usa o algoritmo de clone estruturado - não para gráficos enormes a cada tick
• Arquivo de entrada de worker separado - sem eval: true em produção
• A fila emparelha trabalhos com workers - pools de produção usam bibliotecas maduras ou agendamento robusto

Mergulho Profundo

Como Funciona

• Cada Worker é uma thread com heap JS isolado, exceto memória compartilhada explicitamente compartilhada.
• workerData clonado uma vez na construção.
• parentPort.postMessage assíncrono entre threads - cópias serializadas.
• SharedArrayBuffer + Atomics para contadores sem bloqueio - avançado, cuidado com corridas de dados.

worker_threads vs child_process

Notas de TypeScript

import { isMainThread, parentPort, workerData } from 'node:worker_threads';
 
if (!isMainThread) {
  const { job } = workerData as { job: string };
  parentPort?.postMessage({ ok: true, job });
}

Armadilhas

• Criação de worker por solicitação HTTP - explosão de threads. Correção: pool fixo reutilizado entre solicitações.
• Envio de objetos enormes com frequência - o custo da clonagem domina. Correção: SharedArrayBuffer ou transferência de ArrayBuffer com lista de transferência.
• Estado mutável compartilhado sem Atomics - corridas de dados. Correção: passagem de mensagens padrão; SharedArrayBuffer apenas quando a necessidade for medida.
• Addons nativos não thread-safe - comportamento indefinido. Correção: execute o addon na thread principal ou no modo thread-safe documentado.
• Erros não tratados no worker - emitem evento error - anexar um manipulador ou worker.on('error') trava a supervisão.

Alternativas

FAQs

Relacionado

• Detectando Bloqueio do Loop de Eventos - quando descarregar
• child_process - processos do sistema operacional
• Noções Básicas de Processos - visão geral da decisão
• Melhores Práticas do Loop de Eventos - regras da thread principal

Versões da Pilha: Esta página foi escrita para Node.js 24.18.0 (LTS Ativo), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 e NestJS 11.