Event loop в Node.js: фазы, nextTick и setImmediate

Event loop в Node.js это цикл, который решает, какой callback выполнить следующим, после того как ваш синхронный код закончил работу. Он проходит фазы по постоянному кругу: timers (setTimeout, setInterval), pending callbacks, poll (ввод-вывод, например чтение файлов и данные из сети), check (setImmediate) и close callbacks. После каждого callback'а Node сначала опустошает очередь process.nextTick, а затем очередь промисов, поэтому они всегда выполняются раньше, чем цикл пойдёт дальше.

// 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');

Программа выводит sync, nextTick, promise, setTimeout, то есть в обратном порядке по сравнению с тем, как строки написаны. Синхронный код всегда заканчивается первым, потом Node опустошает очередь nextTick, потом очередь промисов, и только после этого цикл запускается и доходит до фазы timers.

Фазы event loop

Цикл Node взят из libuv, библиотеки на C, через которую Node работает с вводом-выводом. Перед первым оборотом он выполняет таймеры, время которых уже пришло, а затем каждый оборот проходит эти фазы по порядку:

1. Pending callbacks: несколько системных callback'ов, отложенных с прошлого оборота, например некоторые сетевые ошибки.
2. Poll: новые события ввода-вывода и их callback'и (чтение файла закончилось, на сокет пришли данные). Если больше ничего не запланировано, цикл ждёт здесь.
3. Check: callback'и setImmediate.
4. Close callbacks: события 'close', например у уничтоженного сокета.
5. Timers: callback'и setTimeout и setInterval, время которых пришло.

Во многих руководствах timers стоят первыми в каждом обороте: так Node работал до версии 20 (libuv 1.45). В обоих случаях callback'и выполняются в одном и том же порядке: за таймерами одного оборота идёт фаза poll следующего.

Две очереди находятся вне фаз: очередь nextTick и очередь микрозадач (callback'и промисов и queueMicrotask). Node опустошает обе после каждого отдельного callback'а в любой фазе, сначала nextTick. Цикл крутится, пока есть что ждать (таймер, открытый файл или сокет, сервер), и процесс завершается, когда ничего не осталось.

Это собственный цикл Node. В браузере та же идея задач и микрозадач, но нет фаз, нет setImmediate и нет process.nextTick; картину на уровне языка описывает страница про event loop в JavaScript.

process.nextTick и промисы

Обе очереди выполняются до того, как цикл продолжит работу, но они не перемешиваются. Node выполняет всю очередь nextTick, включая tick'и, добавленные во время её выполнения, и только потом очередь промисов. Угадайте порядок:

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

Порядок такой: tick 1, tick 2, tick from tick, promise 1, promise 2. Tick, запланированный внутри другого tick'а, попадает в ту же очередь и всё равно выполняется раньше любого промиса, хотя промис был создан первым.

На верхнем уровне ES-модуля (файла, который использует import) они меняются местами: код самого модуля выполняется внутри задачи промиса, поэтому его callback'и промисов заканчиваются раньше, чем Node доберётся до очереди nextTick. Внутри callback'ов правило «сначала nextTick» действует в обеих системах модулей.

setImmediate и setTimeout(fn, 0)

setTimeout(fn, 0) на самом деле значит «не раньше чем через 1 мс, в фазе timers». setImmediate(fn) значит «в следующей фазе check». Что выполнится первым, зависит от того, где вы их вызываете.

Внутри callback'а ввода-вывода порядок фиксирован. Callback выполняется в фазе poll, сразу за ней идёт фаза check, а фаза timers наступает только после этого:

const fs = require('fs');

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

Программа каждый раз выводит nextTick, setImmediate, setTimeout. Поэтому setImmediate подходит, когда нужно «выполнить это после текущей работы с вводом-выводом».

В главном модуле, вне любых callback'ов, порядок этих двух не фиксирован:

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

Если к старту цикла прошла хотя бы 1 мс, таймер уже готов и выводит строку первым; иначе побеждает setImmediate. Не пишите код, который зависит от любого из этих исходов.

Блокировка event loop

Поток JavaScript один, поэтому callback, который работает долго, останавливает всё остальное: таймеры, callback'и ввода-вывода и, на сервере, все остальные запросы. Задержка таймера это минимум, а не гарантия.

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

Сначала выводится loop finished, затем true: таймер был готов через 10 мс, но не мог выполниться, пока занятый цикл не отдал поток. На сервере такой же цикл внутри обработчика маршрута замораживает все остальные запросы на полсекунды.

Долгую работу нужно разбить на части и между ними давать циклу ход через 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);

Таймер успевает выполниться после части 1. Замените setImmediate(() => work(part + 1)) на work(part + 1) и запустите снова: все три части выполнятся за один раз, и timer выведется последним.

Для работы, которая тяжёлая от начала до конца, например обработки изображений, разбиения мало: вынесите её из главного потока с помощью worker_threads.

Частые ошибки

Рекурсивный вызов process.nextTick. Callback nextTick, который всё время планирует следующий nextTick, не даёт циклу продолжить работу, и таймеры с вводом-выводом голодают. Для повторяющейся работы используйте setImmediate.

Синхронные API на сервере. fs.readFileSync, crypto.pbkdf2Sync и большие вызовы JSON.parse блокируют цикл для всех пользователей. Внутри обработчиков запросов используйте асинхронные версии.

Ожидание, что setTimeout(fn, 0) выполнится сразу. Он выполняется после всего синхронного кода, каждого nextTick и каждого callback'а промиса, и только когда цикл дойдёт до фазы timers.