worker_threads

worker_threads descarga JavaScript pesado para la CPU a hilos paralelos sin generar un nuevo proceso del sistema operativo. Usa workerData, paso de mensajes y, opcionalmente, SharedArrayBuffer para el estado compartido.

Receta

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));

Cuándo usarlo:

• Rondas de bcrypt/scrypt, redimensionamiento de imágenes, generación de PDF en JS
• Transformación de JSON grande o análisis de CSV que bloquea el bucle de eventos
• Mapeo paralelo sobre elementos de trabajo de CPU con un tamaño de pool fijo
• Operaciones criptográficas que no delegan suficientemente al pool de hilos crypto

Ejemplo de trabajo

// 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');
}

Lo que esto demuestra:

• Tamaño del pool limitado: no generes workers ilimitados por solicitud
• postMessage usa el algoritmo de clonación estructurada, no para gráficos enormes en cada tick
• Archivo de entrada de worker separado: no eval: true en producción
• La cola empareja trabajos con workers: los pools de producción usan librerías maduras o una programación robusta

A fondo

Cómo funciona

• Cada Worker es un hilo con un heap de JS aislado, excepto la memoria compartida explícitamente.
• workerData se clona una vez en la construcción.
• parentPort.postMessage es asíncrono entre hilos, copias serializadas.
• SharedArrayBuffer + Atomics para contadores sin bloqueo: avanzado, ten cuidado con las condiciones de carrera.

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 });
}

Errores comunes

• Generar un worker por solicitud HTTP: explosión de hilos. Solución: pool fijo reutilizado entre solicitudes.
• Publicar objetos enormes con frecuencia: el costo de clonación domina. Solución: SharedArrayBuffer o transferir ArrayBuffers con lista de transferencia.
• Estado mutable compartido sin Atomics: condiciones de carrera de datos. Solución: paso de mensajes por defecto; SAB solo cuando se mida la necesidad.
• Addons nativos no seguros para hilos: comportamiento indefinido. Solución: ejecutar el addon en el hilo principal o en modo seguro para hilos documentado.
• Errores no manejados en el worker: emiten el evento error; adjunta un manejador o worker.on('error') bloquea la supervisión.

Alternativas

Preguntas frecuentes

Relacionado

• Detección de bloqueo del bucle de eventos - cuándo descargar
• child_process - procesos del sistema operativo
• Conceptos básicos de procesos - resumen de decisiones
• Mejores prácticas del bucle de eventos - reglas del hilo principal

Versiones de la pila: Esta página fue escrita para Node.js 24.18.0 (LTS activa), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 y NestJS 11.