Запуск рантайма и event loop

От node app.js до вашей первой строки

Сначала не выполняется ничего вашего. Когда вы набираете node app.js, C++-бинарник node поднимает целый рантайм ещё до того, как существует ваш код. Он создаёт изолят V8 (изолированный экземпляр JS-движка с собственной кучей и GC) и контекст (глобальный объект и встроенные функции для этого изолята). Он передаёт V8 платформенную прослойку, чтобы V8 мог ставить задачи обратно в libuv — C-библиотеку, которой принадлежат event loop и примитивы ввода-вывода ОС. Затем libuv инициализирует loop по умолчанию. Дальше Node выполняет свой внутренний JavaScript-bootstrap — тысячи строк, которые подключают process, глобальные объекты (console, Buffer, таймеры) и загрузчики модулей (CommonJS require и ESM-загрузчик). И только после этого загружается ваш входной модуль, и его синхронный код верхнего уровня выполняется сверху вниз до конца.

Эта последняя оговорка и есть вся ментальная модель: ваш код верхнего уровня выполняется синхронно до самого конца, прежде чем сработает хоть один асинхронный колбэк. setTimeout(fn, 0) на строке 1 не выполняется на строке 1 — он регистрирует таймер и продолжает дальше. В loop входят только когда стек вызовов пуст, то есть после того, как ваш модуль завершился. Вот почему длинный синхронный блок на старте задерживает все таймеры и I/O-колбэки, что вы запланировали: все они ждут, пока стек опустеет.

console.log("1: top-level start");
setTimeout(() => console.log("4: timer"), 0);
Promise.resolve().then(() => console.log("3: promise microtask"));
console.log("2: top-level end");

// stdout:
// 1: top-level start
// 2: top-level end          ← сначала завершается весь синхронный код
// 3: promise microtask      ← microtask'и опустошаются до тика loop
// 4: timer                  ← фаза timers у loop, последней

Loop из libuv: фазы в фиксированном порядке

Как только стек пуст, Node входит в loop. У libuv нет одной недифференцированной очереди — есть упорядоченный набор фаз, и каждый тик обходит их в одной и той же последовательности, опустошая собственную очередь колбэков фазы, прежде чем двигаться дальше:

1. timers — колбэки setTimeout/setInterval, у которых истёк порог.
2. pending callbacks — несколько отложенных системных колбэков (например, некоторые коды ошибок TCP).
3. idle / prepare — внутренний учёт; их вы не трогаете никогда.
4. poll — сердце loop. Он вычисляет, на сколько блокироваться, а затем блокируется в ожидании ввода-вывода (новые соединения, данные сокета, завершённая работа fs), запуская их колбэки по мере поступления.
5. check — здесь срабатывают колбэки setImmediate, сразу после poll.
6. close callbacks — socket.on("close") и им подобные.

Фаза poll — это место, где процесс проводит время простоя: когда делать нечего, он спит в epoll_wait (Linux) / kqueue (macOS), пока ядро не сообщит, что файловый дескриптор готов. Именно это уведомление о готовности на уровне ядра — а не threadpool — позволяет Node масштабировать десятки тысяч параллельных сетевых сокетов на одном потоке.

Microtask’и врезаются между всем: nextTick > Promise > loop

Фазы — это макроструктура. Под ними лежат две очереди microtask’ов, которые Node опустошает между каждым колбэком и между переходами фаз — они вообще не являются фазами loop. Порядок фиксирован, и его стоит запомнить:

1. Очередь process.nextTick (специфичная для Node, наивысший приоритет).
2. Очередь задач Promise / queueMicrotask (microtask-очередь ECMAScript).

Обе полностью опустошаются до пустоты, прежде чем loop разрешат продвинуться. Так что глобальный приоритет таков: process.nextTick > Promise/queueMicrotask > setTimeout/setImmediate/I/O. Программа делает это наглядным:

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

// stdout (детерминирован для microtask'ов; порядок timeout/immediate может меняться местами на верхнем уровне):
// sync
// sync end
// nextTick          ← очередь nextTick опустошается первой
// promise           ← затем очередь задач Promise…
// queueMicrotask    ← …в порядке FIFO с promise-задачами
// timeout           ← и только теперь loop тикает свои фазы
// immediate

process.nextTick выполняется раньше Promise — это полезно, когда API должен отложить до «после текущей операции», вовсе не уступая управление loop (например, чтобы эмитить событие, на которое вызывающий ещё не успел подписаться). Тот же приоритет — и его опасность, разбираем ниже.

Threadpool: где «однопоточность» перестаёт быть правдой

JS выполняется на одном потоке, но несколько встроенных операций нельзя сделать неблокирующим системным вызовом, поэтому libuv отгружает их в threadpool: fs.* (файловый I/O), dns.lookup (резолвер по умолчанию, вызывающий блокирующий getaddrinfo), CPU-нагруженный crypto вроде pbkdf2/scrypt/randomBytes и сжатие zlib. Размер пула по умолчанию — 4 (UV_THREADPOOL_SIZE, задаётся вплоть до 1024, и читается лишь однажды при старте). Что важно — сетевой I/O пул не использует: сокеты идут через epoll/kqueue в фазе poll. Так что ваши 10 000 простаивающих сокетов не стоят ничего, но пять параллельных fs.readFile при пуле из четырёх означают, что пятый ждёт слота.