Event loop: один поток, упорядоченные фазы

Разработчик пишет setTimeout(fn, 0) рядом с setImmediate(fn) рядом с Promise.resolve().then(fn), ожидая, что они сработают в порядке исходника. Не сработают. Сначала бежит промис, потом — в зависимости от того, где стоит код — либо таймер, либо immediate. Это не баг и не гонка; это опубликованное расписание event loop. Цикл — не чёрный ящик, который «когда-нибудь выполнит асинхронщину». Это строгая упорядоченная машина, и как только видишь её фазы, тайминг асинхронности перестаёт быть фольклором.

Цикл — это последовательность фаз

Единственный поток из прошлого урока не выполняет колбэки в порядке прихода. Он крутит фиксированную последовательность фаз (в libuv, движке цикла Node), и у каждой фазы своя очередь колбэков, которую надо осушить перед переходом дальше. Те, что важны изо дня в день:

• Timers — колбэки, у которых истёк таймаут setTimeout/setInterval.
• Poll — сердце: получить новые I/O-события и выполнить их колбэки (пришёл HTTP-запрос, закончилось чтение файла). Если ничего не ждёт, цикл блокируется здесь, ожидая на epoll/kqueue — именно здесь проводится время простоя.
• Check — колбэки, запланированные через setImmediate, выполняются сразу после poll.
• Close — колбэки событий закрытия (socket.on('close')).

Один полный проход по фазам — это тик (tick) цикла. Внутри фазы колбэки выполняются по одному, до конца — без вытеснения.

Макрозадачи vs микрозадачи

Два этих слова прячут всю модель тайминга. Очереди фаз держат макрозадачи: колбэк таймера, I/O-колбэк, setImmediate. Отдельно от них — две очереди микрозадач с более высоким приоритетом:

• Колбэки process.nextTick (специфика Node), осушаются первыми.
• Реакции промисов (продолжения .then/await).

Правило: после завершения каждого отдельного колбэка цикл полностью осушает очереди микрозадач, прежде чем выполнить следующий колбэк или сменить фазу. Поэтому Promise.resolve().then(fn) обгоняет setTimeout(fn, 0) — реакция промиса есть микрозадача, выполняемая на ближайшем осушении, тогда как таймер ждёт фазы timers на более позднем тике.

setTimeout(0) vs setImmediate

Эти два — классическая путаница. setImmediate всегда бежит в фазе check, сразу после poll; setTimeout(fn, 0) зажат до минимума ~1 мс и бежит в фазе timers. Внутри I/O-колбэка (то есть уже в poll или сразу после) setImmediate надёжно срабатывает раньше следующей фазы timers, поэтому выигрывает. На верхнем уровне скрипта порядок не гарантирован — он зависит от того, сколько времени цикл потратил на запуск. Старший вывод не в мелочи, а в модели: «сразу после I/O» и «после задержки таймера» — это разные фазы, а не одна очередь.

Кооперативная, не параллельная

Поскольку один поток выполняет каждый колбэк до конца без вытеснения, конкурентность event loop кооперативная: каждый колбэк должен добровольно уступить — завершившись или наткнувшись на await, который отдаёт управление — чтобы выполнился любой другой колбэк. Два запроса никогда не выполняют JavaScript в один и тот же момент; они чередуются в точках уступки. В этом вся сила (никаких локов, никаких гонок данных по разделяемому состоянию внутри тика) и вся слабость (один колбэк, который никогда не уступает, замораживает всё), что следующий урок делает конкретным.