Event loop w Node.js: fazy, nextTick i setImmediate

Event loop w Node.js to pętla, która decyduje, który callback wykona się następny, gdy twój kod synchroniczny już się skończył. Przechodzi przez fazy w stałym cyklu: timers (setTimeout, setInterval), pending callbacks, poll (I/O, np. odczyt plików i dane z sieci), check (setImmediate) i close callbacks. Po każdym callbacku Node najpierw opróżnia kolejkę process.nextTick, a potem kolejkę promise, więc one zawsze wykonują się, zanim pętla pójdzie dalej.

// Guess the order of the four lines, then run it
setTimeout(() => console.log('setTimeout'), 0);

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

process.nextTick(() => console.log('nextTick'));

console.log('sync');

Wypisuje sync, nextTick, promise, setTimeout, czyli odwrotnie niż w kodzie. Kod synchroniczny zawsze kończy się pierwszy, potem Node opróżnia kolejkę nextTick, potem kolejkę promise, i dopiero wtedy pętla rusza i dochodzi do fazy timers.

Fazy event loop

Pętla Node pochodzi z libuv, biblioteki w C, której Node używa do I/O. Przed pierwszym obrotem uruchamia timery, których czas już nadszedł, a potem każdy obrót przechodzi przez te fazy po kolei:

1. Pending callbacks: kilka callbacków systemowych odłożonych z poprzedniego obrotu, np. niektóre błędy sieci.
2. Poll: nowe zdarzenia I/O i ich callbacki (skończył się odczyt pliku, na sockecie pojawiły się dane). Gdy nic innego nie jest zaplanowane, pętla czeka właśnie tutaj.
3. Check: callbacki setImmediate.
4. Close callbacks: zdarzenia 'close', np. zniszczony socket.
5. Timers: callbacki setTimeout i setInterval, których czas już nadszedł.

Wiele poradników stawia timery na początku każdego obrotu, bo tak działał Node przed wersją 20 (libuv 1.45). Callbacki i tak wykonują się w tej samej kolejności: po timerach jednego obrotu przychodzi poll następnego.

Dwie kolejki są poza fazami: kolejka nextTick i kolejka mikrozadań (callbacki promise i queueMicrotask). Node opróżnia obie po każdym pojedynczym callbacku, w każdej fazie, najpierw nextTick. Pętla kręci się dalej, dopóki jest na co czekać (timer, otwarty plik albo socket, serwer), a proces kończy się, gdy nic nie zostało.

To jest własna pętla Node. Przeglądarka ma tę samą ideę tasków i mikrozadań, ale nie ma faz, setImmediate ani process.nextTick; strona o event loop w JavaScript pokazuje obraz na poziomie języka.

process.nextTick vs promise

Oba wykonują się, zanim pętla pójdzie dalej, ale nie są wymieszane. Node wykonuje całą kolejkę nextTick, łącznie z tickami dodanymi w trakcie, i dopiero potem kolejkę promise. Przewidź wynik tego przykładu:

Promise.resolve()
    .then(() => console.log('promise 1'))
    .then(() => console.log('promise 2'));

process.nextTick(() => {
    console.log('tick 1');
    process.nextTick(() => console.log('tick from tick'));
});
process.nextTick(() => console.log('tick 2'));

Kolejność to tick 1, tick 2, tick from tick, promise 1, promise 2. Tick zaplanowany wewnątrz ticka trafia do tej samej kolejki i nadal wykonuje się przed każdym promise, chociaż promise powstał pierwszy.

Na najwyższym poziomie modułu ES (pliku, który używa import) te dwie kolejki zamieniają się miejscami: kod modułu sam wykonuje się wewnątrz zadania promise, więc jego callbacki promise kończą się, zanim Node dojdzie do kolejki nextTick. Wewnątrz callbacków reguła "najpierw nextTick" obowiązuje w obu systemach modułów.

setImmediate vs setTimeout(fn, 0)

setTimeout(fn, 0) tak naprawdę znaczy "po co najmniej 1 ms, w fazie timers". setImmediate(fn) znaczy "w następnej fazie check". To, co wykona się pierwsze, zależy od miejsca, w którym je wywołasz.

Wewnątrz callbacku I/O kolejność jest stała. Callback działa w fazie poll, faza check przychodzi zaraz po niej, a faza timers dopiero potem:

const fs = require('fs');

fs.readFile(__filename, () => {
    setTimeout(() => console.log('setTimeout'), 0);
    setImmediate(() => console.log('setImmediate'));
    process.nextTick(() => console.log('nextTick'));
});

Za każdym razem wypisuje nextTick, setImmediate, setTimeout. Dlatego setImmediate to dobry wybór, gdy chcesz "wykonać to po bieżącej pracy I/O".

W module głównym, poza jakimkolwiek callbackiem, kolejność tych dwóch nie jest ustalona:

// Order depends on how fast the process started
setTimeout(() => console.log('setTimeout'), 0);
setImmediate(() => console.log('setImmediate'));

Jeśli przy starcie pętli minęła co najmniej 1 ms, timer jest już gotowy i wypisuje się pierwszy; w przeciwnym razie wygrywa setImmediate. Nie pisz kodu, który zależy od któregokolwiek z tych wyników.

Blokowanie event loop

Ponieważ jest tylko jeden wątek JavaScript, callback, który działa długo, zatrzymuje wszystko inne: timery, callbacki I/O i na serwerze każde inne żądanie. Opóźnienie timera to minimum, a nie gwarancja.

const start = Date.now();

setTimeout(() => {
    const waited = Date.now() - start;
    console.log('asked for 10 ms, waited 500 ms or more:', waited >= 500);
}, 10);

// A busy loop: holds the thread for half a second
while (Date.now() - start < 500) {}
console.log('loop finished');

Najpierw wypisuje się loop finished, potem true: timer był gotowy po 10 ms, ale nie mógł się wykonać, dopóki pętla zajmująca procesor nie oddała wątku. Na serwerze ta sama pętla w handlerze trasy zamraża każde inne żądanie na pół sekundy.

Rozwiązanie dla długiej pracy to podzielić ją i między kawałkami oddać pętli obrót przez setImmediate:

function busy(ms) {
    const end = Date.now() + ms;
    while (Date.now() < end) {}
}

setTimeout(() => console.log('timer'), 0);

function work(part) {
    busy(50);
    console.log('part', part, 'done');
    if (part < 3) setImmediate(() => work(part + 1));
}
work(1);

Timer wchodzi po części 1. Zamień setImmediate(() => work(part + 1)) na work(part + 1) i uruchom ponownie: wszystkie trzy części wykonują się za jednym razem, a timer wypisuje się na końcu.

Przy pracy, która jest ciężka od początku do końca, np. przetwarzaniu obrazów, dzielenie nie wystarczy: przenieś ją z głównego wątku za pomocą worker_threads.

Częste błędy

Rekurencyjne wywoływanie process.nextTick. Callback nextTick, który ciągle planuje kolejny nextTick, nigdy nie pozwala pętli pójść dalej, więc timery i I/O głodują. Do powtarzanej pracy używaj setImmediate.

Synchroniczne API na serwerze. fs.readFileSync, crypto.pbkdf2Sync i duże wywołania JSON.parse blokują pętlę dla wszystkich użytkowników. W handlerach żądań używaj wersji asynchronicznych.

Oczekiwanie, że setTimeout(fn, 0) wykona się od razu. Wykonuje się po całym kodzie synchronicznym, każdym nextTick i każdym callbacku promise, i dopiero wtedy, gdy pętla dojdzie do fazy timers.