Event loop w JavaScript: jak naprawdę działa kod asynchroniczny

Jednowątkowy, ale nie sekwencyjny

JavaScript działa w jednym wątku. Jest jeden stos wywołań i w każdej chwili wykonuje się dokładnie jedna funkcja. Żadne dwie linie twojego kodu nigdy nie działają równolegle w tym samym realmie.

Brzmi to jak ograniczenie, dopóki nie przypomnisz sobie, co JavaScript naprawdę robi: pobiera dane, czeka na kliknięcia użytkownika, czyta pliki. Większość tej „pracy” to czekanie. Event loop to sztuczka, dzięki której czekanie jest tanie: twój kod przekazuje zadanie przeglądarce lub Node, wraca do innych rzeczy i dostaje powiadomienie, gdy wynik jest gotowy.

console.log("pierwszy");

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

console.log("drugi");

pierwszy i drugi wypisują się po kolei. trzeci pojawia się później, mimo że timeout wynosi 0. Ta przerwa to event loop w działaniu, a zrozumienie, skąd się bierze, to cały sens tej strony.

Stos wywołań

Każde wywołanie funkcji odkłada ramkę na stos wywołań (call stack). Gdy funkcja zwraca wynik, jej ramka jest zdejmowana. Stos to po prostu stos: ostatni wszedł, pierwszy wychodzi.

function inner() {
    return "gotowe";
}

function outer() {
    return inner();
}

console.log(outer());

Gdy wykonuje się outer(), Node odkłada outer, potem inner, następnie zdejmuje inner, gdy ta zwraca "gotowe", a potem zdejmuje outer. Stos znów jest pusty. Właśnie na tę chwilę „pustego stosu” czeka event loop.

Kod synchroniczny wykonuje się na stosie od początku do końca. Nic asynchronicznego nie może go przerwać. Jeśli napiszesz pętlę while (true), stos nigdy się nie opróżni, a strona się zawiesi: żadnych kliknięć, żadnych timerów, żadnych callbacków obietnic. Event loop nie ma nic do roboty, bo nie może dojść do głosu.

Gdzie naprawdę żyje praca asynchroniczna

Sam JavaScript nie wie, jak wysłać żądanie sieciowe ani jak odczekać 100 milisekund. Te API należą do środowiska: przeglądarki lub Node. Gdy wywołujesz setTimeout(fn, 100), dzieje się to:

1. Timer zostaje zarejestrowany w środowisku.
2. setTimeout natychmiast zwraca wynik. Stos działa dalej.
3. Po 100 ms środowisko umieszcza fn w kolejce.
4. Gdy stos jest pusty, event loop zdejmuje fn z kolejki i ją uruchamia.

console.log("start");

setTimeout(() => console.log("timer zadziałał"), 100);

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

console.log("koniec");

Callback timera nie może się wykonać, dopóki nie skończą się pętla for i console.log("koniec"), bo stos nie jest jeszcze pusty. Timery to minimalne opóźnienie, a nie gwarancja.

Dwie kolejki: zadania i mikrozadania

Nie ma jednej kolejki. Są dwie i to rozróżnienie wyjaśnia większość niespodzianek związanych z event loopem.

• Kolejka zadań (task queue, czasem nazywana kolejką makrozadań): setTimeout, setInterval, callbacki wejścia/wyjścia, zdarzenia interfejsu.
• Kolejka mikrozadań (microtask queue): callbacki obietnic (.then, .catch, .finally), kontynuacje po await i wszystko, co zaplanowano przez queueMicrotask.

Zasada, według której działa event loop:

1. Wykonaj jedno zadanie z kolejki zadań.
2. Opróżnij całą kolejkę mikrozadań: każde mikrozadanie, także te zaplanowane w trakcie opróżniania.
3. W razie potrzeby wyrenderuj (w przeglądarkach).
4. Wróć do punktu 1.

Mikrozadania zawsze wykonują się przed następnym zadaniem. Dlatego to zaskakuje:

console.log("sync 1");

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

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

console.log("sync 2");

Kolejność wyjścia: sync 1, sync 2, obietnica, timeout. Najpierw wykonuje się kod synchroniczny. Potem stos się opróżnia. Następnie event loop opróżnia mikrozadania (obietnica). Dopiero wtedy bierze zadanie timera (timeout).

Mikrozadania mogą zagłodzić zadania

Ponieważ kolejka mikrozadań opróżnia się w całości przed następnym zadaniem, mikrozadanie, które wciąż planuje kolejne mikrozadania, zablokuje kolejkę zadań na zawsze:

// Nie uruchamiaj tego naprawdę: to pułapka.
function loop() {
    queueMicrotask(loop);
}

// loop();
// setTimeout(() => console.log("nigdy się nie wykona"), 0);

Timer nigdy by nie zadziałał, bo każde mikrozadanie kolejkuje kolejne mikrozadanie, a pętla nigdy nie pozwala kolejce się opróżnić. Łańcuchy obietnic są bezpieczne, bo każde .then planuje tylko jedną kontynuację, ale ręcznie pisane pętle mikrozadań to pułapka, o której warto wiedzieć.

await to lukier składniowy dla mikrozadania

Gdy używasz await na obietnicy, funkcja się wstrzymuje, a jej reszta zostaje zaplanowana jako mikrozadanie, które wykona się po rozstrzygnięciu obietnicy. Żadnej magii: pod spodem to po prostu .then.

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

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

Wyjście: A, C, B. await oddaje sterowanie kodowi wywołującemu. console.log("C") wykonuje się na bieżącym stosie. Potem kolejka mikrozadań się opróżnia i reszta demo wznawia działanie, wypisując B.

Pamiętaj o tym, czytając kod asynchroniczny. await nie blokuje, tylko ustępuje.

Przykład krok po kroku: kolejność wszystkiego

Połącz wszystkie elementy:

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

Kolejność:

1. 1: sync: wykonuje się na stosie.
2. 6: sync: nadal na stosie.
3. Stos się opróżnia. Kolejka mikrozadań się opróżnia: 3: promise, 5: microtask, a potem 4: nested microtask (zaplanowane w trakcie opróżniania, ale i tak zostaje pobrane).
4. Wykonuje się następne zadanie: 2: timeout.

Końcowe wyjście: 1, 6, 3, 5, 4, 2. Jeśli potrafisz prześledzić ten przykład, rozumiesz event loop.

Node ma więcej faz

Event loop w Node to nadzbiór modelu przeglądarki. Ma odrębne fazy: timers, pending callbacks, poll, check i close, a mikrozadania opróżniają się między każdą fazą. setImmediate wykonuje się w fazie check, a process.nextTick wykonuje się przed zwykłymi mikrozadaniami (ma własną kolejkę o jeszcze wyższym priorytecie).

Pierwszego dnia nie musisz znać diagramu faz na pamięć. Najważniejszy wniosek jest taki sam jak w przeglądarce: kod synchroniczny wykonuje się do końca, potem opróżniają się mikrozadania, a potem pętla bierze następny zakolejkowany callback.

Dlaczego to ma znaczenie

Gdy ten model zaskoczy, wiele kodu asynchronicznego przestaje być tajemnicze:

• Długa pętla for zamraża interfejs, bo event loop nie może dojść do głosu.
• setTimeout(fn, 0) to sposób na odłożenie pracy do chwili, gdy skończą się bieżące zadanie i mikrozadania.
• Callback .then, który uruchamia się „natychmiast” po już rozwiązanej obietnicy, i tak czeka na koniec bieżącego kodu synchronicznego.
• await wewnątrz pętli szereguje pracę, bo każda iteracja przed kontynuacją ustępuje miejsca kolejce mikrozadań.

Debugowanie kodu asynchronicznego sprowadza się głównie do pytania: „co jest teraz na stosie, a co czeka w kolejce?”. Odpowiedzią jest event loop.

Dalej: callbacki

Przed obietnicami i async/await jedynym narzędziem JavaScript do pracy asynchronicznej był callback: funkcja, którą przekazujesz API, żeby wywołało ją później. Callbacki wciąż są wszędzie (nasłuchiwacze zdarzeń, podstawowe API Node), a ich zrozumienie to fundament wszystkiego innego w tym rozdziale.