Worker threads starten en berichten doorgeven

Node.js voert uw JavaScript uit op één thread. Dat is ideaal voor I/O-gebonden werk (HTTP, databases, bestanden), omdat de gebeurtenislus nooit blokkeert. Maar een CPU-gebonden taak — afbeeldingen verkleinen, hashen, grote ladingen parseren, cryptografie — wordt synchroon uitgevoerd en bevriest de volledige server totdat de taak klaar is.

• I/O-gebonden → blijf op de gebeurtenislus en gebruik asynchrone API's.
• CPU-gebonden → draag het werk uit aan een Worker-thread, zodat de hoofdthread aanvragen kan blijven verwerken.

Met de module worker_threads kunt u JavaScript parallel uitvoeren op afzonderlijke threads van het besturingssysteem, elk met een eigen V8-isolate en gebeurtenislus.

U maakt een thread met new Worker(filename). Het bestand wordt op een nieuwe thread uitgevoerd. Gebruik isMainThread om één bestand zich verschillend te laten gedragen afhankelijk van waar het wordt uitgevoerd.

Hieronder start de hoofdthread een worker die naar hetzelfde bestand verwijst. De tak voor de worker voert het werk uit en wordt beëindigd.

Als u bij het aanmaken invoer aan een worker wilt meegeven, geeft u workerData door in het optiesobject. In de worker leest u deze uit de module worker_threads.

• workerData wordt gekloneerd (met structured clone) en niet gedeeld — als u de gegevens in de worker wijzigt, heeft dat geen invloed op de hoofdthread.
• Gebruik dit voor de beginparameters van de taak: een bestandspad, een getallenbereik of configuratie.

workerData werkt slechts in één richting en één keer. Gebruik voor resultaten het berichtenkanaal dat elke worker ingebouwd heeft:

• In de worker: parentPort.postMessage(value) stuurt gegevens naar het bovenliggende proces.
• Op de hoofdthread: worker.on('message', cb) ontvangt de gegevens.

Berichten zijn asynchroon en worden gekloond met structured clone, zodat de hoofdthread responsief blijft terwijl de worker rekent.

Het kanaal werkt in beide richtingen. Het bovenliggende proces kan worker.postMessage() gebruiken en de worker luistert met parentPort.on('message', ...). Zo wordt een worker een service met een lange levensduur die veel taken verwerkt in plaats van één.

Let erop dat de worker actief blijft luisteren naar berichten; u moet expliciet aangeven dat deze moet stoppen (hier activeert een null-sentinel process.exit).

In backendcode wilt u meestal een nette asynchrone functie: u roept deze aan en gebruikt await voor een resultaat. Verpak de levenscyclus van de worker in een Promise: los deze op bij message en wijs deze af bij error of een niet-nulwaarde van exit.

Dit patroon vormt de basis van elke workerpool: één promise per taak.

Berichten worden gekopieerd met het structured-clone-algoritme, niet met JSON.stringify. Dat betekent dat u meer kunt versturen dan alleen gewone JSON.

• Ondersteund: objecten, arrays, Map, Set, Date, RegExp, ArrayBuffer, getypeerde arrays en BigInt.
• Niet ondersteund: functies, instanties van classes met methoden, DOM-achtige objecten en alles met closures — deze veroorzaken een DataCloneError.

Het klonen van grote objecten kost CPU en geheugen. Geef voor grote binaire buffers de voorkeur aan overdragen in plaats van kopiëren (in de volgende scène).

Voor grote binaire gegevens is kopiëren verspilling. Geef een overdrachtslijst als tweede argument mee aan postMessage. Het eigendom van de ArrayBuffer wordt naar de andere thread verplaatst — zonder kopiëren — en de buffer wordt onbruikbaar op de verzendende thread (de waarde van byteLength wordt 0).

Gebruik dit voor afbeeldingsbytes, bestandsdelen of elke lading van megabyteschaal om het dupliceren van geheugen te voorkomen.

Naast de ingebouwde parentPort kunt u met new MessageChannel() uw eigen kanaal maken. Dit levert twee gekoppelde poorten op: port1 en port2. Houd er één bij, draag de andere over aan een worker en u hebt een speciaal communicatiekanaal — handig om besturingsberichten van gegevens te scheiden of voor communicatie tussen workers.

Een MessagePort kan zelf worden overgedragen. U stuurt deze dus mee in workerData of in een bericht met een overdrachtslijst.

Een worker kan crashen. Koppel altijd de gebeurtenissen van de levenscyclus eraan, zodat een mislukte taak niet stilletjes een aanvraag laat hangen:

• 'error' — een niet-afgevangen uitzondering in de worker.
• 'exit' — wordt één keer geactiveerd; code is bij een fout niet nul.
• 'messageerror' — een bericht kon niet worden gedeserialiseerd.

Roep vanuit de hoofdthread worker.terminate() aan om een worker te stoppen (dit retourneert een promise). Workers die niet worden beëindigd, houden het proces actief.

In een echte Node.js-backend start u niet voor elke aanvraag een worker — het opstarten van een thread is duur. In plaats daarvan:

• Houd een kleine pool van workers met een lange levensduur bij (vaak os.cpus().length).
• Stuur elke CPU-gebonden taak via postMessage en koppel resultaten aan een id.
• Reserveer workers voor werk dat echt CPU-gebonden is en laat I/O op de gebeurtenislus.

Dit voorbeeld toont het berichtenprotocol per worker, waarbij een id wordt gebruikt om aanvraag en antwoord aan elkaar te koppelen — het kernidee waarop elke poolbibliotheek (zoals piscina) voortbouwt.

U weet nu hoe u workers start en gegevens tussen threads verplaatst:

• Starten met new Worker(file, { workerData }); vertakken op basis van isMainThread.
• Resultaten versturen met parentPort.postMessage() en ontvangen via worker.on('message') — het kanaal werkt in twee richtingen.
• Berichten gebruiken structured clone (rijker dan JSON, maar zonder functies); grote buffers moeten via een overdrachtslijst worden overgedragen om kopiëren te voorkomen.
• Maak extra communicatiekanalen met MessageChannel en draag een MessagePort over voor zijkanalen of communicatie tussen workers.
• Behandel altijd error/exit en roep terminate() aan; gebruik in productie een pool met berichten die via id's aan elkaar zijn gekoppeld, in plaats van één worker per aanvraag.