Event loop in JavaScript: come funziona il codice async

Un solo thread, ma non sequenziale

JavaScript gira su un solo thread. C'è una sola call stack e, in ogni momento, viene eseguita esattamente una funzione. Nello stesso realm, due righe del tuo codice non girano mai in parallelo.

Sembra un limite finché non pensi a cosa fa davvero JavaScript: recupera dati, aspetta i clic dell'utente, legge file. La maggior parte del "lavoro" è attesa. L'event loop è il trucco che rende l'attesa economica: il tuo codice passa un compito al browser o a Node, torna a fare altro e riceve un avviso quando il risultato è pronto.

console.log("primo");

setTimeout(() => console.log("terzo"), 0);

console.log("secondo");

primo e secondo vengono stampati in ordine. terzo arriva dopo, anche se il timeout è 0. Quello scarto è l'event loop al lavoro, e capire il perché è lo scopo di tutta questa pagina.

La call stack

Ogni chiamata di funzione aggiunge un frame alla call stack. Quando la funzione restituisce un valore, il suo frame viene tolto. La stack è semplicemente una pila: l'ultimo che entra è il primo che esce.

function inner() {
    return "fatto";
}

function outer() {
    return inner();
}

console.log(outer());

Quando viene eseguita outer(), Node mette sulla pila outer, poi inner, toglie inner quando restituisce "fatto" e poi toglie outer. La pila è di nuovo vuota. Quel momento di "pila vuota" è proprio ciò che l'event loop sta aspettando.

Il codice sincrono gira dall'inizio alla fine sulla stack. Niente di asincrono può interromperlo. Se scrivi un ciclo while (true), la stack non si svuota mai e la pagina si blocca: niente clic, niente timer, niente callback delle promise. L'event loop non ha niente da fare perché non gli arriva mai il turno.

Dove vive davvero il lavoro asincrono

JavaScript da solo non sa fare una richiesta di rete né aspettare 100 millisecondi. Quelle API appartengono all'host: il browser o Node. Quando chiami setTimeout(fn, 100), ecco cosa succede:

1. Il timer viene registrato presso l'host.
2. setTimeout restituisce subito il controllo. La stack continua a girare.
3. Dopo 100ms, l'host mette fn in una coda.
4. Quando la stack è vuota, l'event loop prende fn dalla coda e la esegue.

console.log("inizio");

setTimeout(() => console.log("timer scattato"), 100);

for (let i = 0; i < 3; i++) {
    console.log("ciclo", i);
}

console.log("fine");

La callback del timer non può essere eseguita finché il ciclo for e console.log("fine") non hanno finito, perché la stack non è ancora vuota. I timer indicano un ritardo minimo, non una garanzia.

Due code: task e microtask

Non c'è una sola coda. Ce ne sono due, e la differenza spiega la maggior parte delle sorprese dell'event loop.

• Task queue (a volte chiamata macrotask queue): setTimeout, setInterval, callback di I/O, eventi della UI.
• Microtask queue: callback delle promise (.then, .catch, .finally), continuazioni di await e tutto ciò che viene programmato con queueMicrotask.

La regola che segue l'event loop:

1. Esegue un task dalla task queue.
2. Svuota tutta la microtask queue: ogni microtask, compresi quelli programmati mentre la sta svuotando.
3. Esegue il rendering se serve (nei browser).
4. Torna al punto 1.

I microtask vengono sempre eseguiti prima del task successivo. Ecco perché questo esempio sorprende molti:

console.log("sync 1");

setTimeout(() => console.log("timeout"), 0);

Promise.resolve().then(() => console.log("promise"));

console.log("sync 2");

Ordine dell'output: sync 1, sync 2, promise, timeout. Prima gira il codice sincrono. Poi la stack si svuota. Poi l'event loop svuota i microtask (promise). Solo a quel punto prende il task del timer (timeout).

I microtask possono affamare i task

Visto che la coda dei microtask si svuota completamente prima del task successivo, un microtask che continua a programmare altri microtask blocca per sempre la task queue:

// Non eseguirlo davvero: è una trappola.
function loop() {
    queueMicrotask(loop);
}

// loop();
// setTimeout(() => console.log("non viene mai eseguito"), 0);

Il timer non scatterebbe mai, perché ogni microtask ne mette in coda un altro e il loop non lascia mai svuotare la coda. Le catene di promise sono sicure perché ogni .then programma una sola continuazione, ma i cicli di microtask scritti a mano sono una trappola che conviene conoscere.

await è zucchero sintattico per un microtask

Quando fai await su una promise, la funzione si mette in pausa e il resto viene programmato come microtask, da eseguire quando la promise si conclude. Niente di magico: sotto c'è semplicemente un .then.

async function demo() {
    console.log("A");
    await Promise.resolve();
    console.log("B");
}

demo();
console.log("C");

Output: A, C, B. L'await restituisce il controllo a chi ha chiamato la funzione. console.log("C") gira sulla stack corrente. Poi la coda dei microtask si svuota e il resto di demo riprende, stampando B.

Tienilo a mente quando leggi codice asincrono. await non blocca: cede il controllo.

Un esempio completo: mettere tutto in ordine

Mettiamo insieme tutti i pezzi:

console.log("1: sync");

setTimeout(() => console.log("2: timeout"), 0);

Promise.resolve().then(() => {
    console.log("3: promise");
    queueMicrotask(() => console.log("4: nested microtask"));
});

queueMicrotask(() => console.log("5: microtask"));

console.log("6: sync");

Ordine:

1. 1: sync: gira sulla stack.
2. 6: sync: sempre sulla stack.
3. La stack si svuota. La coda dei microtask viene svuotata: 3: promise, 5: microtask, poi 4: nested microtask (programmato durante lo svuotamento, viene comunque preso in questo giro).
4. Viene eseguito il task successivo: 2: timeout.

Output finale: 1, 6, 3, 5, 4, 2. Se riesci a seguire questo esempio, hai capito l'event loop.

Node ha più fasi

L'event loop di Node è un'estensione del modello del browser. Ha fasi distinte (timers, pending I/O callbacks, poll, check, close) e i microtask vengono svuotati tra una fase e l'altra. setImmediate gira nella fase check, mentre process.nextTick gira prima dei microtask normali (ha una sua coda con priorità ancora più alta).

Non serve imparare a memoria lo schema delle fasi il primo giorno. Il concetto chiave è lo stesso del browser: il codice sincrono gira fino alla fine, poi si svuotano i microtask, poi il loop prende la prossima callback in coda.

Perché è importante

Quando il modello ti è chiaro, molto codice asincrono smette di essere un mistero:

• Un ciclo for lungo blocca la UI perché l'event loop non riesce ad avere il suo turno.
• setTimeout(fn, 0) è un modo per rimandare del lavoro a dopo la fine del task corrente e dei microtask.
• Una callback .then che parte "subito" su una promise già risolta aspetta comunque la fine del codice sincrono corrente.
• Un await dentro un ciclo serializza il lavoro, perché ogni iterazione cede il passo alla coda dei microtask prima di continuare.

Fare debug di codice asincrono significa soprattutto chiedersi: "cosa c'è sulla stack in questo momento, e cosa c'è in coda?". L'event loop è la risposta.

Prossimo argomento: le callback

Prima delle promise e di async/await, l'unico strumento di JavaScript per il lavoro asincrono era la callback: una funzione che passi a un'API perché la chiami più tardi. Le callback sono ancora ovunque (event listener, API di base di Node), e capirle è la base di tutto il resto di questo capitolo.