Запустите несколько строк с setTimeout и обещанием, и порядок вывода может вас удивить. Цикл событий JavaScript объясняет, почему. Это механизм, который позволяет однопоточному языку обрабатывать таймеры, сетевые вызовы и щелчки без зависаний.

Как только вы это поймете, целый класс запутанных ошибок начнет обретать смысл. Мы запускали каждый пример на Node.js 24, и в результате этого запуска были получены выходные данные. Основные правила упорядочивания также применяются в браузерах, и мы указываем, в чем отличия Node.js. Вы получите больше от этого, если уже знаете основы обещаний JavaScript.

Почему существует цикл событий

JavaScript выполняет ваш код в одном основном потоке, поэтому одновременно выполняется только одна его часть. Если бы он просто ждал сетевого запроса, страница зависала бы до тех пор, пока не придет ответ.

Так что JavaScript не ждет. Медленная работа передается хост-среде, то есть браузеру или Node.js, который может обрабатывать ее в фоновом режиме. Когда эта работа завершается, обратный вызов помещается в очередь. Задача цикла событий — переместить обратные вызовы из очереди в стек, когда он свободен.

Представьте себе шеф-повара, работающего в одиночку. Шеф-повар ставит блюдо в духовку и устанавливает таймер, а не смотрит на него. Когда прозвенит таймер, задание попадает в список, и шеф-повар берет его в руки после того, как выполнит то, что сейчас находится в руках.

Движущиеся части

Задачи иногда называют макрозадачами. Строго говоря, источников задач может быть несколько, и точные детали различаются в зависимости от среды.

Правила

1. Запускайте весь синхронный код, пока стек вызовов не станет пустым.
2. Запустите все микрозадачи, включая любые новые, добавленные по пути.
3. В браузере отобразите обновление, если оно необходимо.
4. Возьмите одну задачу из очереди и запустите ее.
5. Вернитесь к шагу 2.

Самая важная деталь: все микрозадачи, затем одна задача. Большинство загадок цикла событий решаются применением этого единственного правила.

Посмотреть заказ

console.log("1 sync");
setTimeout(() => console.log("5 timeout"), 0);
Promise.resolve().then(() => console.log("3 promise"));
queueMicrotask(() => console.log("4 microtask"));
console.log("2 sync");

// 1 sync
// 2 sync
// 3 promise
// 4 microtask
// 5 timeout

Вот что произошло. Две строки console.log синхронны, поэтому они выполняются первыми. Обратный вызов промиса и queueMicrotask попали в очередь микрозадач и запустились, как только стек опустел, в том порядке, в котором они были добавлены. Обратный вызов таймера должен был дождаться хода задачи, хотя его задержка была равна нулю.

Микрозадачи выполняются между таймерами

После каждой отдельной задачи очередь микрозадач снова очищается. Этот пример доказывает это:

setTimeout(() => {
  console.log("timer 1");
  Promise.resolve().then(() => console.log("promise inside timer 1"));
}, 0);
setTimeout(() => console.log("timer 2"), 0);

// timer 1
// promise inside timer 1
// timer 2

Промис, созданный во время первого таймера, выполнялся до второго таймера. Современные браузеры и Node.js 11 и более поздних версий ведут себя таким образом.

Где ожидание подходит

await разбивает функцию на две части. Все, что происходит до него, выполняется синхронно, а все, что происходит после него, запланировано как микрозадача. Многих это удивляет:

async function task() {
  console.log("A before await");
  await null;
  console.log("C after await");
}

task();
console.log("B after calling task");

// A before await
// B after calling task
// C after await

Функция async не запускается в фоновом режиме. Он выполняется в том же потоке, пока не достигнет своего первого await. Это применимо даже в случае ожидания чего-то, что не является настоящим обещанием, например null. Дополнительную информацию об этом синтаксисе можно найти в нашем руководстве по асинхронному/ожиданию JavaScript.

Блокировка петли

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

const start = Date.now();
setTimeout(() => console.log("timer ran after", Date.now() - start, "ms"), 0);
while (Date.now() - start < 500) {}

// timer ran after about 500 ms

Задержка таймера — это минимум, а не гарантия. Он запустился только тогда, когда стек освободился. На веб-странице такой длинный цикл означает, что клики не реагируют и анимация останавливается. На сервере каждый второй запрос должен ждать, поэтому один медленный синхронный вызов может нанести вред всем пользователям процесса Node.js.

Общие причины блокировки включают огромные циклы, анализ очень больших JSON, синхронные файловые функции, такие как readFileSync ​​в обработчиках запросов, и катастрофические регулярные выражения.

Оставайтесь отзывчивыми

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

const items = [0, 1, 2, 3, 4];

async function processAll() {
  for (const item of items) {
    if (item === 2) await new Promise((r) => setTimeout(r, 0));
    console.log("item", item);
  }
}

setTimeout(() => console.log("other work gets a turn"), 0);
processAll();

// item 0
// item 1
// other work gets a turn
// item 2
// item 3
// item 4

Другой таймер сработал посередине, потому что мы выполнили настоящую задачу. Реальный код будет выдавать каждые несколько элементов или миллисекунд. Для действительно ресурсоемкой работы, например обработки изображений, используйте веб-воркер в браузерах или рабочий поток в Node.js, который выполняется в отдельных потоках.

голодание микрозадач

Поскольку цикл полностью очищает очередь микрозадач перед тем, как двигаться дальше, микрозадача, которая продолжает планировать больше, может остановить все остальное. Мы протестировали это на 100 000 связанных микрозадачах:

let count = 0;
let timerFired = false;
setTimeout(() => { timerFired = true; }, 0);

function spin() {
  count++;
  if (count < 100000) queueMicrotask(spin);
  else console.log("timer fired during microtasks?", timerFired);
}
queueMicrotask(spin);

// timer fired during microtasks? false

Таймер не мог работать, пока все они не будут выполнены. Если бы эта цепочка никогда не заканчивалась, таймеры никогда бы не сработали, а в браузере страница никогда не перерисовывалась бы. Обратите внимание, что использование await для решенного обещания здесь не поможет, поскольку оно просто добавляет еще одну микрозадачу. Вам нужна реальная задача, например таймер, чтобы дать возможность другим.

Рендеринг в браузерах

Браузер обычно получает возможность рисовать между задачами. Это объясняет распространенную ошибку:

spinner.hidden = false;
doHeavyWork();              // blocks the thread
spinner.hidden = true;

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

Отличия Node.js

Node.js имеет собственный цикл событий с несколькими этапами, включая таймеры, опрос ввода-вывода и setImmediate. У него также есть process.nextTick, который выполняется в отдельной очереди. Вот что мы увидели при запуске их изнутри асинхронной функции:

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

// promise
// nextTick
// immediate
// timeout

Во многих статьях утверждается, что nextTick всегда лучше обещаний, а таймер лучше setImmediate. Наш результат показывает, что все не так просто. Наш код уже выполнялся в рамках микрозадачи, поэтому очередь обещаний выполнялась первой. А порядок setTimeout и setImmediate, как известно, варьируется в зависимости от того, откуда они вызываются. Поэтому не пишите код, который зависит от их точного порядка. Если одно событие должно происходить за другим, четко свяжите их.

Интервью-викторина

Прежде чем прочитать ответ, постарайтесь определить порядок:

console.log("a");
setTimeout(() => console.log("b"), 0);
Promise.resolve().then(() => {
  console.log("c");
  setTimeout(() => console.log("d"), 0);
  Promise.resolve().then(() => console.log("e"));
});
console.log("f");

Наш прогон напечатал a, f, c, e, b, d. Вот почему:

1. a и f синхронны, поэтому они выполняются первыми.
2. Стек пуст, поэтому выполняются микрозадачи: c, затем новая микрозадача e в том же раунде.
3. Теперь одна задача: таймер b, который был поставлен в очередь первым.
4. Затем следующая задача: таймер d, который был поставлен в очередь во время выполнения микрозадачи.

Распространенные ошибки

• Мышление setTimeout является точным. Задержка минимальна.
• Мышление async означает другой поток. Асинхронный код по-прежнему выполняется в основном потоке между ожиданиями.
• Использование спящих режимов для исправления порядка. Ожидание фактического состояния гораздо надежнее, что также относится к ненадежным тестам.
• Использование forEach с await. Между элементами нет ожидания. См. Методы массивов JavaScript.
• Выполнение тяжелой синхронной работы в обработчике сервера. Один запрос может задержать любой другой запрос.

Итоги

Помните основное правило: запускайте стек, пока он не опустеет, запустите все микрозадачи, затем запустите одну задачу и повторите. Из этого следует все остальное. Чтобы он прижился, напишите свою собственную версию приведенного выше теста, спрогнозируйте результат на бумаге, а затем запустите его. Ошибка и понимание ее причины научат вас большему, чем любая диаграмма.

Часто задаваемые вопросы

Продолжайте учиться