Voer een paar regels uit met setTimeout en een belofte, en de uitvoervolgorde zal u misschien verrassen. De JavaScript-gebeurtenislus legt uit waarom. Het is het mechanisme waarmee een taal met één thread timers, netwerkoproepen en klikken kan verwerken zonder te bevriezen.

Als je het eenmaal begrijpt, begint een hele reeks verwarrende bugs logisch te worden. We hebben elk voorbeeld uitgevoerd op Node.js 24 en de uitvoer komt uit die run. De belangrijkste bestelregels zijn ook van toepassing in browsers, en we wijzen erop waar Node.js verschilt. U zult hier meer uit halen als u de basisprincipes van JavaScript-beloften al kent.

Waarom de gebeurtenislus bestaat

JavaScript voert uw code uit op één hoofdthread, zodat er slechts één deel tegelijk wordt uitgevoerd. Als er simpelweg op een netwerkverzoek werd gewacht, zou een pagina vastlopen totdat het antwoord terugkwam.

JavaScript wacht dus niet. Het trage werk wordt overgedragen aan de hostomgeving, dat wil zeggen de browser of Node.js, die het op de achtergrond afhandelt. Wanneer dat werk klaar is, wordt er teruggebeld in een wachtrij. De taak van de gebeurtenislus is om callbacks in de wachtrij naar de stapel te verplaatsen wanneer deze vrij is.

Denk aan een chef-kok die alleen werkt. De chef-kok zet een gerecht in de oven en stelt een timer in, in plaats van ernaar te staren. Als de timer afgaat, wordt de taak op een lijst gezet, en de chef-kok pakt deze op nadat hij klaar is met wat hij op dat moment in handen heeft.

De bewegende delen

Taken worden soms macrotaken genoemd. Strikt genomen kunnen er meerdere taakbronnen zijn, en de exacte details verschillen per omgeving.

De regels

1. Voer alle synchrone code uit totdat de call-stack leeg is.
2. Voer alle microtaken uit, inclusief eventuele nieuwe die onderweg worden toegevoegd.
3. Geef in een browser een update weer als deze nodig is.
4. Neem één taak uit een wachtrij en voer deze uit.
5. Ga terug naar stap 2.

Het belangrijkste detail: alle microtaken, daarna één taak. De meeste gebeurtenisluspuzzels worden opgelost door die ene regel toe te passen.

Zie de bestelling

console.log("1 sync");
setTimeout(() => console.log("5 timeout"), 0);
Promise.resolve().then(() => console.log("3 promise"));
queueMicrotask(() => console.log("4 microtask"));
console.log("2 sync");

// 1 sync
// 2 sync
// 3 promise
// 4 microtask
// 5 timeout

Dit is wat er gebeurde. De twee console.log lijnen zijn synchroon, dus ze liepen als eerste. De belofte callback en queueMicrotask gingen naar de microtask-wachtrij en werden uitgevoerd zodra de stapel leeg was, in de volgorde waarin ze werden toegevoegd. De terugbeltimer moest wachten op een taakbeurt, ook al was de vertraging nul.

Microtaken worden uitgevoerd tussen timers

Na elke afzonderlijke taak wordt de wachtrij voor microtaken weer geleegd. Dit voorbeeld bewijst het:

setTimeout(() => {
  console.log("timer 1");
  Promise.resolve().then(() => console.log("promise inside timer 1"));
}, 0);
setTimeout(() => console.log("timer 2"), 0);

// timer 1
// promise inside timer 1
// timer 2

De belofte, die tijdens de eerste timer tot stand kwam, liep vóór de tweede timer. Moderne browsers en Node.js 11 en later gedragen zich op deze manier.

Waar wachten past

await splitst een functie in tweeën. Alles ervoor loopt synchroon, en alles erna is gepland als een microtaak. Dit verbaast veel mensen:

async function task() {
  console.log("A before await");
  await null;
  console.log("C after await");
}

task();
console.log("B after calling task");

// A before await
// B after calling task
// C after await

Een async-functie start niet op de achtergrond. Het loopt op dezelfde draad totdat het zijn eerste await bereikt. Dat geldt zelfs als je wacht op iets dat geen echte belofte is, zoals null. Zie onze JavaScript async/await-handleiding voor meer informatie over deze syntaxis.

Het blokkeren van de lus

Terwijl synchrone code wordt uitgevoerd, kan niets anders dat doen. Om dit te laten zien, hebben we een timer ingesteld op 0 ms en de thread vervolgens een halve seconde bezig gehouden:

const start = Date.now();
setTimeout(() => console.log("timer ran after", Date.now() - start, "ms"), 0);
while (Date.now() - start < 500) {}

// timer ran after about 500 ms

De vertraging van de timer is een minimum en is geen garantie. Het liep alleen toen de stapel vrijkwam. Op een webpagina betekent een lange lus als deze dat klikken niet reageren en animaties stoppen. Op een server moet elk ander verzoek wachten. Daarom kan één langzame synchrone oproep alle gebruikers van een Node.js-proces schade toebrengen.

Veelvoorkomende oorzaken van blokkering zijn enorme lussen, het parseren van zeer grote JSON, synchrone bestandsfuncties zoals readFileSync in verzoekhandlers, en catastrofale reguliere expressies.

Responsief blijven

Geef de evenementenlus bij zwaar werk de kans om te ademen. Eén manier is om af en toe een timer te pauzeren, waardoor andere taken kunnen worden uitgevoerd:

const items = [0, 1, 2, 3, 4];

async function processAll() {
  for (const item of items) {
    if (item === 2) await new Promise((r) => setTimeout(r, 0));
    console.log("item", item);
  }
}

setTimeout(() => console.log("other work gets a turn"), 0);
processAll();

// item 0
// item 1
// other work gets a turn
// item 2
// item 3
// item 4

De andere timer liep in het midden, omdat we toegaven met een echte taak. Echte code zou om de zoveel items of milliseconden opleveren. Voor echt CPU-zwaar werk, zoals beeldverwerking, gebruikt u een Web Worker in browsers of een werkthread in Node.js, die op afzonderlijke threads draaien.

Uithongering door microtaken

Omdat de lus de wachtrij voor microtaken volledig leegmaakt voordat verder wordt gegaan, kan een microtaak die steeds meer taken plant, al het andere tegenhouden. We hebben dit getest met 100.000 gekoppelde microtaken:

let count = 0;
let timerFired = false;
setTimeout(() => { timerFired = true; }, 0);

function spin() {
  count++;
  if (count < 100000) queueMicrotask(spin);
  else console.log("timer fired during microtasks?", timerFired);
}
queueMicrotask(spin);

// timer fired during microtasks? false

De timer kon pas lopen als ze allemaal klaar waren. Als die keten nooit zou eindigen, zouden timers nooit worden geactiveerd, en in een browser zou de pagina nooit opnieuw worden geschilderd. Merk op dat toegeven met await aan een opgeloste belofte hier niet helpt, omdat het alleen maar een extra microtaak toevoegt. Je hebt een echte taak nodig, zoals een timer, om anderen een beurt te geven.

Renderen in browsers

Een browser krijgt meestal de kans om tussen taken door te schilderen. Dat verklaart een veel voorkomende bug:

spinner.hidden = false;
doHeavyWork();              // blocks the thread
spinner.hidden = true;

De spinner verschijnt nooit, omdat de browser geen mogelijkheid had om tussen die regels weer te geven. Om het probleem op te lossen, laat u een frame passeren voordat het zware werk begint, of verplaatst u dat werk naar een arbeider. Voor code die beelden verandert, wordt requestAnimationFrame vlak voor de volgende verf uitgevoerd, waardoor dit het juiste hulpmiddel voor animatie is.

Node.js-verschillen

Node.js heeft zijn eigen gebeurtenislus met verschillende fasen, waaronder timers, I/O-polling en setImmediate. Het heeft ook process.nextTick, dat in zijn eigen wachtrij draait. Dit is wat we zagen toen we deze vanuit een asynchrone functie uitvoerden:

setTimeout(() => console.log("timeout"), 0);
setImmediate(() => console.log("immediate"));
process.nextTick(() => console.log("nextTick"));
Promise.resolve().then(() => console.log("promise"));

// promise
// nextTick
// immediate
// timeout

In veel artikelen wordt gesteld dat nextTick beloften altijd overtreft, en dat een timer beter is dan setImmediate. Ons resultaat laat zien dat het niet zo eenvoudig is. Onze code draaide al binnen een microtaak, dus de beloftewachtrij ging als eerste door. En het is bekend dat de volgorde van setTimeout en setImmediate varieert, afhankelijk van waar ze vandaan worden gebeld. Schrijf dus geen code die afhankelijk is van de exacte volgorde hiervan. Als het ene na het andere moet gebeuren, koppel ze dan expliciet aan elkaar.

Interviewquiz

Probeer de volgorde uit te werken voordat je het antwoord leest:

console.log("a");
setTimeout(() => console.log("b"), 0);
Promise.resolve().then(() => {
  console.log("c");
  setTimeout(() => console.log("d"), 0);
  Promise.resolve().then(() => console.log("e"));
});
console.log("f");

Onze oplage drukte a, f, c, e, b, d. Dit is waarom:

1. a en f zijn synchroon, dus ze lopen als eerste.
2. De stapel is leeg, dus microtaken worden uitgevoerd: c, daarna de nieuwe microtaak e, in dezelfde ronde.
3. Nu één taak: timer b, die als eerste in de wachtrij stond.
4. Dan de volgende taak: timer d, die tijdens de microtaak in de wachtrij stond.

Veel voorkomende fouten

• Het denken setTimeout is exact. De vertraging is slechts een minimum.
• Nadenken async betekent een nieuwe thread. Asynchrone code wordt tussen de wachttijden nog steeds op de hoofdthread uitgevoerd.
• Het gebruik van sleeps om de bestelling te corrigeren. Het wachten op de daadwerkelijke toestand is veel betrouwbaarder, wat ook geldt voor slechte tests.
• Gebruik forEach met await. Er wordt niet gewacht tussen items. Zie JavaScript-arraymethoden.
• Zwaar synchroon werk doen in een serverhandler. Eén verzoek kan elk ander verzoek vertragen.

Tot slot

Onthoud de kernregel: voer de stapel uit totdat deze leeg is, voer alle microtaken uit, voer dan één taak uit en herhaal. Al het overige volgt daaruit. Om ervoor te zorgen dat het blijft hangen, schrijft u uw eigen versie van de bovenstaande quiz, voorspelt u de uitkomst op papier en voert u deze vervolgens uit. Als je er één fout maakt en begrijpt waarom, leer je meer dan welk diagram dan ook.

Veelgestelde vragen

Blijf leren