nextTick и микрозадачи: две очереди между колбэками

Тик — не фаза, а довесок к текущему колбэку: цикл осушает очередь тиков, как только колбэк вернулся, и лишь потом берёт следующий. Это модель уже умеет. Чего она не знает — что очередей в этом перерыве две. Первая держит колбэки process.nextTick, вторая — реакции промисов: .then, .catch, .finally, продолжение кода после await и queueMicrotask. Порядок между ними жёсткий: сначала вся первая, потом вся вторая.

Делить их приходится потому, что они разного происхождения. Микроочередь — часть языка: её держит движок, и в браузере она ровно такая же, только соседствует там не с тиками, а с макрозадачами браузерного цикла. Очередь тиков — собственность Node: в браузере process нет вовсе. Node разбирает свою очередь первой и только после этого отдаёт ход микрозадачам.

В модели это одно поле micro, один назначатель loop.microtask и новый перерыв внутри call. Всё остальное осталось как было: фазы, часы, снимок очереди на входе в фазу и сон до ближайшего срока. Прогноз к первому примеру: колбэк фазы проверки назначает две работы в одну очередь и две в другую, вперемешку, — в каком порядке они напечатаются и где окажется строка «колбэк кончился»?

// Тот же планировщик, но перерыв между колбэками теперь держит две очереди
const loop = {
  timers: [], // фаза сроков: колбэки loop.timeout
  poll: [], // фаза опроса: колбэки готового ввода-вывода
  check: [], // фаза проверки: колбэки loop.immediate
  ticks: [], // очередь тиков: осушается первой
  micro: [], // очередь микрозадач: после тиков
  now: 0, // часы цикла, в тиках
  turn: 0, // номер оборота
};

// срок — это «не раньше»: ноль превращается в один тик, как ноль Node — в миллисекунду
loop.timeout = (fn, delay = 0) => loop.timers.push({ fn, due: loop.now + Math.max(1, delay) });
loop.io = (fn) => loop.poll.push(fn); // байты пришли: колбэк готов к фазе опроса
loop.immediate = (fn) => loop.check.push(fn);
loop.nextTick = (fn) => loop.ticks.push(fn);
loop.microtask = (fn) => loop.micro.push(fn);

// колбэк доиграл — и до следующего идёт перерыв: тики до дна, потом микрозадачи до дна
const call = (fn) => {
  fn();
  do {
    while (loop.ticks.length > 0) loop.ticks.shift()();
    while (loop.micro.length > 0) loop.micro.shift()();
  } while (loop.ticks.length > 0); // микрозадача успела назначить тик — начинаем круг заново
};

loop.run = () => {
  while (loop.timers.length + loop.poll.length + loop.check.length > 0) {
    loop.turn += 1;
    // в этом обороте работы нет — цикл спит до ближайшего срока, а не крутится вхолостую
    if (loop.poll.length === 0 && loop.check.length === 0) {
      loop.now = Math.max(loop.now, Math.min(...loop.timers.map((t) => t.due)));
    }
    // фаза сроков: наступившие таймеры, самый ранний первым
    const due = loop.timers.filter((t) => t.due <= loop.now).sort((a, b) => a.due - b.due);
    loop.timers = loop.timers.filter((t) => t.due > loop.now);
    for (const timer of due) call(timer.fn);
    // фазы опроса и проверки: очередь берётся такой, какой она была на входе в фазу
    for (const fn of loop.poll.splice(0)) call(fn);
    for (const fn of loop.check.splice(0)) call(fn);
    loop.now += 1; // оборот занял тик
  }
};

// колбэк фазы проверки назначает две работы в одну очередь и две в другую, вперемешку
loop.immediate(() => {
  console.log('колбэк начался');
  loop.nextTick(() => console.log('тик 1'));
  loop.microtask(() => console.log('микрозадача 1'));
  loop.nextTick(() => console.log('тик 2'));
  loop.microtask(() => console.log('микрозадача 2'));
  console.log('колбэк кончился');
});
loop.run();

Порядок вывода — не порядок назначения, а порядок очередей: оба тика, потом обе микрозадачи. А «колбэк кончился» стоит раньше их всех, и это главное в примере: обе очереди — перерыв между колбэками, а не часть колбэка. Пока колбэк не вернулся, ни один тик и ни одна микрозадача не выполняются, сколько бы их ни назначили.

Имя в модели своё, как и раньше: loop.microtask — это и .then, и queueMicrotask, и продолжение после await. В Node всё это одна и та же очередь.

Слово «до дна» стоит понимать буквально: очередь разбирается, пока не опустеет, включая работы, назначенные по дороге. С одной очередью это просто, с двумя — интереснее. Что будет, если тик по ходу работы заведёт микрозадачу, а микрозадача — тик? Первая попадёт в очередь, которая ещё не начиналась. А вторая — в ту, которую только что объявили пустой.

Семь строк, семь работ. Выпишите их порядок, прежде чем нажимать Run: дальше он повторится на настоящем Node, и сверять будет интереснее.

// тик по ходу работы заводит микрозадачу, а микрозадача — тик: где окажется каждая
loop.immediate(() => {
  loop.nextTick(() => {
    console.log('тик 1');
    loop.nextTick(() => console.log('тик 1.1, назначен из тика'));
    loop.microtask(() => console.log('микрозадача из тика 1'));
  });
  loop.nextTick(() => console.log('тик 2'));
  loop.microtask(() => {
    console.log('микрозадача 1');
    loop.nextTick(() => console.log('тик из микрозадачи 1'));
  });
  loop.microtask(() => console.log('микрозадача 2'));
});
loop.run();

Разберём по шагам. тик 1.1 встал в конец очереди тиков и выполнился в том же заходе — очередь живая, не снимок, в отличие от очередей фаз. микрозадача из тика 1 попала во вторую очередь, до которой ход ещё не дошёл, и разобралась вместе с остальными. А вот тик из микрозадачи 1 заставил цикл вернуться к первой очереди: в call за это отвечает do…while, который начинает круг заново, пока очередь тиков пополняется.

Поэтому «сначала тики, потом микрозадачи» — не два шага, а круг. Перерыв кончится только тогда, когда обе очереди окажутся пустыми одновременно; до этого цикл не вернётся ни в одну фазу.

Проверим настоящим node. Тот же набор, только loop.nextTick стал process.nextTick, loop.microtask — Promise.resolve().then, а loop.immediate — setImmediate.

// Две очереди между колбэками: в каком порядке их разбирают и куда попадает то,
// что назначено по ходу разбора.

// колбэк фазы проверки назначает два тика и две реакции промиса; первый тик и
// первый промис по ходу добавляют к очередям ещё по одной работе
setImmediate(() => {
  console.log('колбэк начался');

  process.nextTick(() => {
    console.log('тик 1');
    process.nextTick(() => console.log('тик 1.1, назначен из тика'));
    Promise.resolve().then(() => console.log('промис из тика 1'));
  });
  process.nextTick(() => console.log('тик 2'));

  Promise.resolve().then(() => {
    console.log('промис 1');
    process.nextTick(() => console.log('тик из промиса 1'));
  });
  Promise.resolve().then(() => console.log('промис 2'));

  console.log('колбэк кончился');
});

колбэк начался
колбэк кончился
тик 1
тик 2
тик 1.1, назначен из тика
промис 1
промис 2
промис из тика 1
тик из промиса 1

Порядок работ — тот же, что в модели, вплоть до последней. Две строки про начало и конец колбэка стоят здесь рамкой: всё остальное напечаталось уже после того, как он вернулся. Значит, do…while в call не украшение и не вольность автора: именно так Node и разбирает свои очереди. Осушил тики, осушил микрозадачи, посмотрел, не появилось ли новых тиков, — и заново.

Правило «сначала тики» описывает перерыв между колбэками. Верхний уровень главного модуля — не колбэк: ни одной фазы ещё не прошло, а очереди уже пополняются. Что происходит с ними там, проще увидеть, чем вывести. Прогноз: одни и те же четыре строки стоят в трёх местах — на верхнем уровне main.mjs, в колбэке setImmediate и на верхнем уровне обычного файла CommonJS. Везде ли порядок одинаков?

// Один и тот же набор назначений в трёх местах: верх ES-модуля, колбэк цикла и
// верх файла CommonJS. Порядок двух очередей везде ли одинаков?
import { execFileSync } from 'node:child_process';

const четыре = (где) => {
  process.nextTick(() => console.log(`${где}: тик 1`));
  Promise.resolve().then(() => console.log(`${где}: промис 1`));
  process.nextTick(() => console.log(`${где}: тик 2`));
  Promise.resolve().then(() => console.log(`${где}: промис 2`));
};

четыре('верх ES-модуля');

setImmediate(() => {
  четыре('колбэк');
  setImmediate(() => {
    // тот же код верхним уровнем CommonJS: увидеть его старт можно только
    // отдельным процессом — главный модуль у процесса один
    process.stdout.write(execFileSync(process.execPath, ['top.cjs'], { cwd: import.meta.dirname }));
  });
});

верх ES-модуля: промис 1
верх ES-модуля: промис 2
верх ES-модуля: тик 1
верх ES-модуля: тик 2
колбэк: тик 1
колбэк: тик 2
колбэк: промис 1
колбэк: промис 2
верх CommonJS: тик 1
верх CommonJS: тик 2
верх CommonJS: промис 1
верх CommonJS: промис 2

В колбэке — знакомый порядок, а на верхнем уровне main.mjs он обратный. Причина в том, как Node выполняет ES-модуль: тело модуля для загрузчика — работа промиса, и микроочередь осушается ещё внутри этой работы, до того как Node доберётся до очереди тиков. У файла CommonJS никакого промиса нет — его тело выполняет require, и порядок там обычный, тиковый. Одно и то же содержимое, а расширение и поле type меняют вывод местами.

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

Модель здесь молчит, и честно будет это назвать. У неё нет ни загрузчика, ни главного модуля: колбэки приходят только из фаз, а тик, назначенный в примере до loop.run(), пролежит в очереди до первого же колбэка — осушает её только call. Это первая из нескольких вещей, о которых модель говорит увереннее, чем вправе; остальные разберём в статье «Где модель врёт: планировщик на промисах и замкнутость мира».

У обещания «до дна» есть цена. Очередь, которая пополняет себя сама, не опустеет никогда, и перерыв между колбэками не кончится. В браузере это уже было: бесконечная цепочка микрозадач не даёт странице ни перерисоваться, ни услышать клик. В Node к этому добавляется вторая очередь, и цепочка тиков голодит не только цикл, но и микрозадачи: до них ход не дойдёт, пока очередь тиков не опустеет.

В модели это видно буквально — внутренний while по очереди тиков. Колбэк опроса назначает таймер на ноль, микрозадачу и цепочку из пяти тиков. Прогноз: сколько шагов цепочки пройдёт, прежде чем выполнится микрозадача, и сколько — прежде чем наступит таймер?

// ШАГОВ — ограничитель: без него внутренний while очереди тиков не кончится никогда
const ШАГОВ = 5;
let сделано = 0;
loop.io(() => {
  loop.timeout(() => console.log(`таймер: оборот ${loop.turn}, шагов позади ${сделано}`), 0);
  loop.microtask(() => console.log(`микрозадача: шагов позади ${сделано}`));
  const шаг = () => {
    сделано += 1;
    if (сделано < ШАГОВ) loop.nextTick(шаг);
  };
  loop.nextTick(шаг);
});
loop.run();

Оба дождались конца цепочки: и микрозадача, назначенная раньше первого шага, и таймер, который не мог наступить, пока цикл не вернулся в фазу сроков. Пятёрка в ограничителе — не украшение: без неё внутренний while не кончился бы никогда, и вкладка с примером перестала бы отвечать. В настоящем процессе вышло бы то же самое, только вешать там нечего, кроме сервера.

А цепочка в другой очереди — так же беспощадна? Не совсем, и разница ровно в том, что мы видели в разделе про круг. Прогноз: тот же ограничитель, но шаги идут микрозадачами, и рядом два тика — один назначен до первого шага, другой изнутри цепочки. Сколько шагов увидит каждый?

// цепочка микрозадач с тем же ограничителем; один тик назначен до неё, другой — из неё
const ШАГОВ = 5;
let сделано = 0;
loop.io(() => {
  loop.nextTick(() => console.log(`тик, назначенный до цепочки: шагов позади ${сделано}`));
  const шаг = () => {
    сделано += 1;
    if (сделано === 1) loop.nextTick(() => console.log(`тик, назначенный из цепочки: шагов позади ${сделано}`));
    if (сделано < ШАГОВ) loop.microtask(шаг);
  };
  loop.microtask(шаг);
});
loop.run();

Первый тик прошёл вперёд цепочки, не потеряв ни шага: очередь тиков разбирается раньше микроочереди, и цепочка, которой ещё не дали ход, ему не помеха. Второму повезло меньше — он появился, когда очередь тиков уже объявили пустой, и дождался конца всей цепочки. Отсюда несимметричность: цепочка микрозадач голодит цикл и те тики, которые появятся позже, а цепочка тиков голодит вдобавок всю микроочередь целиком.

Настоящий node — с числом, при котором сомнения в «медленно, но дойдёт» отпадают: миллион шагов в каждой очереди. Прогноз: успеет ли таймер на ноль вклиниться хоть куда-нибудь?

// Голодание цикла: миллион шагов в очереди между колбэками — и таймер на ноль рядом.
const ШАГОВ = 1_000_000;

// таймер на ноль: в спокойном цикле он наступил бы на ближайшем обороте
function опыт(имя, отложить, дальше) {
  let сделано = 0;
  let таймерБыл = false;
  setTimeout(() => {
    таймерБыл = true;
    console.log(`${имя}: таймер дождался, шагов к этому моменту ${сделано}`);
    дальше();
  }, 0);
  const шаг = () => {
    сделано += 1;
    if (сделано < ШАГОВ) отложить(шаг);
    else console.log(`${имя}: ${сделано} шагов позади, таймер за это время не сработал: ${таймерБыл ? 'нет' : 'да'}`);
  };
  шаг();
}

опыт('тики', (шаг) => process.nextTick(шаг), () => {
  опыт('промисы', (шаг) => Promise.resolve().then(шаг), () => {});
});

тики: 1000000 шагов позади, таймер за это время не сработал: да
тики: таймер дождался, шагов к этому моменту 1000000
промисы: 1000000 шагов позади, таймер за это время не сработал: да
промисы: таймер дождался, шагов к этому моменту 1000000

Обе цепочки довели счёт до миллиона, и только после этого цикл добрался до фазы сроков. Дело не в скорости: рекурсивная цепочка в любой из двух очередей — это синхронный код, разложенный на кусочки, с той разницей, что внешне он выглядит асинхронным. Сервер в это время не принимает соединения, не отвечает на пинги и не закрывается по сигналу.

Способов отложить работу теперь четыре, и выбирают между ними не по скорости, а по тому, кого при этом пропускают вперёд. Первые два не отдают ход циклу вообще, вторые два отдают. Считаем, как и в прошлой таблице, самый частый случай — назначение из колбэка фазы опроса.

Тик берут, когда довесок обязан случиться раньше любого ввода-вывода и раньше любой реакции промиса, — например, чтобы сообщить о событии так, чтобы вызвавшая сторона успела подписаться (это вторая задача статьи). Микрозадачи обычно не выбирают вовсе: они получаются сами, как только в коде появляется await. А всё, что может подождать до конца оборота, откладывают через setImmediate.

Обратное правило важнее прямого: в этих двух очередях не должно быть ничего длинного и ничего рекурсивного. Порция работы, которая назначает следующую порцию тиком или промисом, — это тот же блокирующий счёт, только записанный так, что при чтении кода он выглядит безобидно. Резать счёт на порции через setImmediate вы уже умеете; а когда порции не спасают, счёт уносят из цикла совсем — в отдельный поток, и это статья «Заблокировать цикл и вынести счёт в отдельный поток».