{
  "index": 318,
  "slug": "editorial-2019-03-practice-event-loop",
  "title": "Event loop без догадок: как отличить порядок callback от блокировки UI",
  "excerpt": "Promise-обработчик может прийти раньше таймера, а интерфейс — перестать отвечать. Разбираем две причины по наблюдаемым меткам, профилю и явному критерию готовности.",
  "contentHtml": "<p>Симптом обычно формулируют неточно: «асинхронность поменяла порядок» или «таймер не сработал вовремя». На странице это выглядит конкретнее: обработчик <code>Promise.then</code> пишет в лог раньше <code>setTimeout</code>, а после импорта данных кнопка несколько мгновений не отвечает. Если начать менять задержки на глаз, можно скрыть один запуск и оставить ту же блокировку на другом устройстве. Цена ошибки — потерянное действие пользователя и повторная отправка данных.</p>\n<p>Маршрут проверки состоит из двух независимых опытов. Сначала мы записываем порядок синхронных строк, Promise-реакции и timer callback. Затем отдельно создаём длинную синхронную работу и измеряем её границы через <code>performance.now()</code>. Так одна проблема распадается на две: неожиданная очередность и занятый главный поток.</p>\n<h2>Что именно наблюдаем</h2>\n<p>В браузерном коде полезно различать текущую синхронную функцию, задачу event loop и microtask checkpoint. Promise-реакция ставится в очередь микрозадач и не прерывает уже исполняющуюся функцию. Когда текущая задача заканчивается, браузер выполняет checkpoint и обрабатывает очередь микрозадач; только после этого event loop выбирает следующую задачу. Callback таймера тоже не появляется в середине этой функции: истекшая задержка делает его кандидатом на будущую задачу. Отсюда первое правило: «через ноль миллисекунд» означает не «немедленно».</p>\n<p>Нельзя сводить всё к одной универсальной очереди. HTML-стандарт оперирует очередями задач и источниками задач; браузер выбирает, что исполнить дальше по собственному алгоритму. Поэтому для реального сбоя важно записать происхождение каждого callback: пользовательское событие, timer, сетевое завершение, Promise-цепочка или ваш прямой вызов. Один только номер строки в Console не доказывает порядок между разными источниками.</p>\n<div class=\"table-scroll\"><table><thead><tr><th scope=\"col\">Наблюдаемый фрагмент</th><th scope=\"col\">Куда попадает работа</th><th scope=\"col\">Что не обещает механизм</th><th scope=\"col\">Первая проверка</th></tr></thead><tbody><tr><td>Обычный вызов функции</td><td>Текущий стек JavaScript</td><td>Что браузер отрисует до возврата из функции</td><td>Поставить отметки до и после вызова</td></tr><tr><td><code>Promise.resolve().then(...)</code></td><td>Promise Job, который host запускает как microtask</td><td>Прерывание текущей синхронной функции</td><td>Сравнить место отметки с концом текущего стека</td></tr><tr><td><code>setTimeout(fn, 0)</code></td><td>Будущая задача после истечения минимальной задержки</td><td>Точный момент запуска и превосходство над другими источниками задач</td><td>Записать метку внутри callback, не только перед постановкой</td></tr><tr><td>Тяжёлый цикл или parse JSON</td><td>Тот же текущий стек</td><td>Реакцию на input, пока цикл не вернул управление</td><td>Измерить начало и конец работы, посмотреть performance trace</td></tr></tbody></table></div>\n<p>Эта таблица не заменяет спецификацию конкретного API. Она нужна для первого разворота расследования. Если в лог попал <code>fetch</code>, сначала устанавливаем, что именно логируется: момент старта запроса, Promise после ответа или собственная функция разбора. Обещание «всё async» здесь бесполезно — важна граница, на которой ваш код вернул управление браузеру.</p>\n<h2>Минимальный опыт с порядком callback</h2>\n<p>Откройте чистую вкладку браузера и вставьте пример в Console либо во временный модуль страницы. Он не измеряет скорость сети и не сравнивает браузеры. Он фиксирует только относительный порядок четырёх точек внутри одного сценария. Время сохраняем рядом с названием, но проверяем именно список меток: абсолютные миллисекунды зависят от нагрузки и точности часов.</p>\n<pre><code>const marks = [];\n\nfunction mark(label) {\n  marks.push({ label, at: performance.now() });\n}\n\nmark(&#039;A: sync start&#039;);\n\nsetTimeout(() =&gt; {\n  mark(&#039;C: timer task&#039;);\n  console.table(marks);\n}, 0);\n\nPromise.resolve().then(() =&gt; {\n  mark(&#039;B: Promise microtask&#039;);\n});\n\nmark(&#039;D: sync end&#039;);</code></pre>\n<p>Для этого опыта ожидаемая причинная запись — <code>A</code>, затем <code>D</code>, затем <code>B</code>, затем <code>C</code>. Сначала заканчивается текущий синхронный фрагмент. После него браузер выполняет microtask checkpoint, в котором может отработать Promise-реакция. Таймерная задача берётся позже, когда event loop выберет следующую доступную работу. Не подменяйте это ожидание тестом вроде «разница всегда ровно 0 или 4 ms»: такого договора у кода нет.</p>\n<p>Полезнее добавить к каждой отметке источник. В проекте через неделю появится ещё один <code>then</code> или debounce, и голый лог <code>1, 2, 3</code> перестанет объяснять причину. Название <code>search: parsed response</code> или <code>filter: timer commit</code> делает цепочку пригодной для диффа между двумя запусками. Временную диагностику затем удаляем либо оставляем под локальным флагом, чтобы не слать шум в production-логи.</p>\n<figure><img src=\"/assets/editorial/2019/event-loop-order-2019.svg\" alt=\"Схема порядка: синхронный стек заканчивается первым, затем выполняется Promise microtask, после чего event loop может взять timer-задачу\" loading=\"lazy\" /><figcaption>Минимальный опыт проверяет последовательность A → D → B → C; задержка таймера не является обещанием точной секунды запуска.</figcaption></figure>\n<h2>Опыт с зависанием: Promise не выносит вычисление</h2>\n<p>Вторая ошибка звучит так: «обернём тяжёлую функцию в Promise — интерфейс перестанет виснуть». Если внутри Promise сразу выполняется большой цикл, всё остаётся на том же главном потоке. <code>Promise.resolve().then(run)</code> лишь переносит начало <code>run</code> в microtask; сама функция всё равно занимает поток целиком, пока не вернёт управление. Пользовательский input и следующая отрисовка ждут эту границу.</p>\n<pre><code>const button = document.createElement(&#039;button&#039;);\nbutton.type = &#039;button&#039;;\nbutton.textContent = &#039;Запустить проверку&#039;;\ndocument.body.append(button);\n\nfunction blockFor(milliseconds) {\n  const startedAt = performance.now();\n\n  while (performance.now() - startedAt &lt; milliseconds) {\n    // Искусственная нагрузка для опыта. Результат вычисления не важен.\n  }\n}\n\nbutton.addEventListener(&#039;click&#039;, () =&gt; {\n  Promise.resolve().then(() =&gt; {\n    const startedAt = performance.now();\n    blockFor(120);\n    const finishedAt = performance.now();\n\n    console.log(&#039;sync work duration&#039;, finishedAt - startedAt);\n  });\n});</code></pre>\n<p>Число <code>120</code> здесь — параметр искусственного опыта, не обещание метрики для сайта. После клика смотрим два факта: длительность, записанную самим сценарием, и виден ли этот участок в профиле производительности. Пока выполняется цикл, другой click handler на этой же странице не начнёт JavaScript-работу. Если нужно сравнить правки, запускайте один и тот же сценарий с той же входной строкой и фиксируйте условия: браузер, профиль CPU и размер данных.</p>\n<p>Не пытайтесь обнаружить это периодическим «пингом таймера» в боевом коде. Он может сам менять картину и не укажет, какой стек занял время. Для расследования достаточно trace в инструментах браузера; для поддерживаемых сред можно отдельно проверить доступность <code>PerformanceObserver</code> с типом <code>longtask</code>. Даже если такой API доступен, отсутствие записи не оправдывает ощущаемую пользователем задержку и не заменяет trace.</p>\n<h2>Как отделить очередь от блокирующего кода</h2>\n<p>Сбой порядка и зависание часто встречаются рядом, но лечатся по-разному. Если лог показывает, что значение из Promise приходит раньше timer callback, это может быть штатный порядок microtask и задачи. Правка состоит в явной зависимости: вызвать следующий шаг в нужном <code>then</code>, вернуть Promise из функции или хранить состояние в одном месте. Добавлять случайную задержку нельзя: она создаёт гонку, а не контракт.</p>\n<p>Если callback начинает работать поздно, а в профиле перед ним виден длинный синхронный участок, причина другая. Находим работу, которую можно сократить, разбить на куски или перенести в worker. Перенос в <code>setTimeout</code> даёт event loop возможность выбрать другие задачи между порциями, но не делает вычисление быстрым и не гарантирует кадр после каждой порции. Сначала измеряем одну порцию, затем выбираем её размер по данным, а не по красивому числу в коде.</p>\n<h2>Последовательность проверки</h2>\n<ol><li>Сформулировать один наблюдаемый симптом: какая кнопка, какой лог или какое состояние оказалось не в том порядке. Сохранить входные данные и шаги воспроизведения.</li><li>Поставить именованные отметки до прямого вызова, после него, внутри Promise-реакции и внутри timer callback. К отметке добавить <code>performance.now()</code> и источник события.</li><li>Проверить относительный порядок на минимальном примере. Не переносить его автоматически на сетевой ответ, worker или другой tab.</li><li>Если есть задержка интерфейса, снять performance trace и найти участок синхронной работы на main thread. Отделить ваш код от layout, GC и стороннего скрипта.</li><li>Для зависимости по данным вернуть Promise или передать результат явным аргументом. Для CPU-работы сократить, нарезать или вынести расчёт; не маскировать причину дополнительным timeout.</li><li>Повторить сценарий с прежними входными данными. Критерий готовности — понятный порядок меток и измеренная граница тяжёлой работы, а не один случай без ошибки.</li></ol>\n<h2>Практический выбор действия</h2>\n<p>Если функция должна начаться строго после HTTP-ответа, пусть вызывающая сторона получает Promise и строит дальнейший шаг в его цепочке. Если пользователь меняет фильтр несколько раз, добавьте номер запроса или отмену там, где это поддерживается, — не рассчитывайте, что Promise упорядочит независимые ответы сети. Если на главном потоке происходит сортировка тысяч записей, сначала проверяем, не нужна ли сортировка полностью, затем рассматриваем порции или worker. Это три разные задачи, хотя в Console они могут выглядеть одинаковым «опозданием».</p>\n<p>Текст намеренно не называет универсальный размер порции и не обещает, что один API лечит каждый freeze. Размер зависит от объёма данных, устройства, текущего DOM и конкурирующей работы. Хорошая техническая заметка оставляет читателю не рецепт «добавить timeout», а инструмент: измерить порядок, обнаружить синхронную границу и выбрать действие, соответствующее именно ей.</p>\n<h2>Ограничения опыта</h2>\n<ul><li>Пример рассчитан на окно браузера. Модель очередей Node.js и поведение worker имеют собственные детали; их нельзя выводить из одного лога в tab.</li><li>Временная шкала нужна для сравнения точек одного запуска. Точность и доступное разрешение времени зависят от окружения и политики браузера.</li><li>Между разными источниками задач не следует строить бизнес-логику по случайному порядку. Передавайте зависимость явно через данные или Promise.</li><li>Длинный участок в trace может включать не только JavaScript. Перед переписыванием цикла надо увидеть, что именно занимает main thread.</li></ul>\n<h2>Итог</h2>\n<p>Promise не выполняется «раньше всего», а таймер не запускается «ровно через ноль». Сначала заканчивается текущий JavaScript, затем выполняется доступная microtask-работа, после чего event loop выбирает будущую задачу. Когда экран завис, ищем не слово async, а длинную синхронную границу. Этот порядок делает диагноз проверяемым: лог даёт последовательность, профиль даёт длительность, а исправление привязано к конкретной причине.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://html.spec.whatwg.org/multipage/webappapis.html#event-loops\" target=\"_blank\" rel=\"noopener noreferrer\">HTML Standard: Event loops</a> — модель очередей задач, выбор следующей задачи и microtask checkpoint в браузере</li><li><a href=\"https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-jobs-and-job-queues\" target=\"_blank\" rel=\"noopener noreferrer\">ECMAScript: Jobs and Job Queues</a> — языковая модель Job и host hook для постановки Promise-реакции</li><li><a href=\"https://www.w3.org/TR/hr-time-3/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C High Resolution Time</a> — семантика монотонной временной шкалы и метода performance.now()</li></ul>"
}