Worker Threads ermöglichen es Node, JavaScript auf separaten Threads mit echtem Parallelismus auszuführen — die Lösung für Nodes größte Einschränkung: CPU-intensive Arbeiten blockieren den einzelnen Haupt-Thread (und damit alle Anfragen). Verwende sie für intensive Berechnungen, nicht für I/O (das der Event Loop bereits effizient handhabt).
app.(, {
result = ();
res.(result);
});
Node führt dein JS auf einem Thread aus. Eine lange synchrone Berechnung blockiert alles — die Event Loop kann andere Anfragen nicht verarbeiten, bis sie beendet ist. Worker Threads verschieben diese Arbeit aus dem Haupt-Thread.
// main.js
import { Worker } from "worker_threads";
function runHeavyTask(data) {
return new Promise((resolve, reject) => {
const worker = new Worker("./worker.js", { workerData: data }); // runs on a NEW thread
worker.on("message", resolve); // receive the result
worker.on("error", reject);
worker.on("exit", (code) => { if (code !== 0) reject(new Error(`exit ${code}`)); });
});
}
// the main thread stays free to handle other requests while this runs
const result = await runHeavyTask({ numbers: [...] });
// worker.js — runs in parallel, on its own thread
import { workerData, parentPort } from "worker_threads";
const result = expensiveComputation(workerData); // doesn't block the main thread
parentPort.postMessage(result); // send the result back
Der Worker läuft unabhängig; der Haupt-Thread stellt weiterhin Anfragen zur Verfügung und erhält das Ergebnis über eine Nachricht, wenn es fertig ist.
✓ USE for CPU-bound work: image/video processing, encryption, compression,
big data parsing, complex calculations, ML inference
✗ DON'T use for I/O (DB, files, HTTP) — the async event loop already handles
that efficiently; a worker would add overhead for no benefit
Die Regel: Worker für CPU-bound, Event Loop für I/O-bound.
worker_threads → share memory (efficient data passing), in-process threads — CPU work
child_process → separate OS processes, run other programs — heavier isolation
cluster → fork the whole server across CPUs — scale request handling
Worker Threads beheben Nodes Kernenschwäche — CPU-bound-Aufgaben blockieren die Single-Threaded Event Loop und frieren alle gleichzeitigen Anfragen ein.
Zu wissen, dass man intensive Berechnungen zu einem Worker verschieben sollte (um den Haupt-Thread responsiv zu halten), und entscheidend wann man sie einsetzen sollte (nur CPU-bound, niemals für I/O), ermöglicht es einem Node-Service, gelegentliche intensive Verarbeitung zu bewältigen, ohne die Parallelität zu opfern, die Node wertvoll macht.
Für das Pooling von Workern in der Produktion verwalten Bibliotheken wie Piscina einen Thread-Pool effizient.