Пулы воркеров, Comlink и наблюдаемость в продакшене

Вы перенесли 400 мс задачу обработки изображения в воркер. Затем пользователи начинают быстро кликать, и страница накапливает пятьдесят ожидающих задач, каждая порождает новый воркер, который никогда не убивается. Вкладка теперь потребляет 400 МБ и убивается на мобильных устройствах.

Когда воркеры окупаются — и когда нет

Запуск воркера не бесплатен: новый realm, новый event loop, свежая копия импортированных скриптов — обычно 5–20 мс старта плюс несколько МБ памяти. Воркер окупается, когда:

• Задача долгая (десятки мс и более), так что старт амортизируется.
• Стоимость передачи результата мала относительно вычислений.

Чистый убыток — когда задача короткая: накладные расходы на postMessage round-trip и клон могут превысить саму работу.

Для повторяющихся мелких задач: держите пул воркеров вместо порождения воркера на каждую задачу.

Пул воркеров

Пул амортизирует стоимость запуска и ограничивает память:

размер пула = navigator.hardwareConcurrency − 1  // оставить одно ядро для главного потока

Компоненты:

1. N воркеров, созданных однажды и переиспользуемых.
2. Очередь задач — ожидающая работа для свободного воркера.
3. Диспетчер — при поступлении задачи: если воркер свободен, отправить; иначе добавить в очередь.

Паттерн пула устраняет повторные расходы на старт и ограничивает суммарную память воркеров.

Backpressure. Без ограничения очереди она растёт неограниченно под нагрузкой. Два варианта:

• Сбрасывать старейшие задачи в очереди.
• Отклонять новые задачи (возвращать rejected promise), чтобы вызывающий код мог притормозить.

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

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

MessageChannel и BroadcastChannel

MessageChannel создаёт прямой двунаправленный канал между двумя конечными точками без участия главного потока:

const { port1, port2 } = new MessageChannel();
worker1.postMessage({ port: port1 }, [port1]); // передать port1 воркеру 1
worker2.postMessage({ port: port2 }, [port2]); // передать port2 воркеру 2
// Теперь воркеры общаются напрямую через порты

Это устраняет главный поток как посредника для воркер-воркер коммуникации — задача критична для пайплайнов (воркер-продюсер → воркер-консюмер) без bottle-neck главного потока.

BroadcastChannel делает то, что его название говорит — транслирует одно сообщение всем слушателям одного origin, включая другие вкладки:

const bc = new BroadcastChannel('app-events');
bc.postMessage({ type: 'theme-changed', value: 'dark' });
// Все вкладки и воркеры, слушающие 'app-events', получают это

Это не замена SharedWorker (у которого один JS realm, единый разделяемый кеш), а более простой pub/sub канал когда вам нужно только широковещательное событие, а не разделяемое состояние.

Ошибка DOM-in-a-worker

Самая частая архитектурная ошибка: команды хватаются за воркер для «ускорения рендеринга» и обнаруживают, что воркер вообще не может трогать DOM. Воркер может вычислить что нужно рендерить, но не рендерить — результат должен быть отправлен обратно и применён главным потоком.

Если узким местом является сама мутация DOM (вставка 10 000 узлов, гигантская React-сверка), воркер не помогает — дорогая часть всё равно должна происходить на главном потоке. Воркеры помогают, когда узкое место — чистые вычисления, дающие небольшой результат:

• Парсить 5 МБ JSON (воркер) → отправить массив из 200 строк (дёшево) → главный поток рендерит 200 строк (быстро). ✓
• React-сверка 10 000 узлов (узкое место — commit, а не деривация) — воркер не поможет. ✗

Исключение: OffscreenCanvas. Canvas-рендеринг можно делать из воркера. Передайте OffscreenCanvas, и воркер рисует 2D или WebGL полностью вне главного потока.

Comlink и иллюзия RPC

Comlink делает await worker.heavyCompute(data) похожим на локальный вызов, оборачивая воркер в Proxy. Это эргономично, но абстракция скрывает две стоимости, которые по-прежнему важны:

1. Каждый аргумент structured-clone’d, если явно не обёрнут в Comlink.transfer.
2. Каждый вызов — task hop в обе стороны — round-trip сообщение между потоками.

Иллюзия рушится для chatty интерфейсов — API воркера со многими мелкими методами в цикле платит task hop за каждый вызов и сериализует программу на round-trip’ах. Проектируйте интерфейсы воркеров coarse: один вызов, делающий batch работы и возвращающий batch результатов, а не много мелкозернистых вызовов. Тот же принцип, что в дизайне сетевого API: минимизируйте round-trip, максимизируйте работу на round-trip.

Утечки памяти воркеров в SPA

В SPA-компонентах воркеры — распространённый источник утечек памяти. Паттерн:

// НЕПРАВИЛЬНО — утечка воркера на каждый remount
useEffect(() => {
  const worker = new Worker('processor.js');
  worker.onmessage = handleResult;
  // нет cleanup!
}, []);

// ПРАВИЛЬНО — cleanup при размонтировании
useEffect(() => {
  const worker = new Worker('processor.js');
  worker.onmessage = handleResult;
  return () => worker.terminate(); // убиваем при размонтировании
}, []);

Каждый useEffect без cleanup создаёт нового воркера при каждом remount (навигация туда-сюда в SPA, React StrictMode двойной монтаж в dev). После дюжины навигаций накапливается пул мёртвых воркеров, которые никто намеренно не создавал.

Обнаружение: DevTools → Performance → Threads показывает все активные воркеры. Неожиданные idle-потоки — утечки. В Chrome DevTools Memory можно сделать heap snapshot: утечающие воркеры видны как DedicatedWorkerGlobalScope с ненулевым retained size.

Наблюдаемость в продакшене

Каждый воркер и каждый service worker — отдельный контекст в DevTools. Веб-воркеры появляются в списке потоков панели Sources. Service workers имеют выделенную панель в Application → Service Workers.

Телеметрия через потоки:

• Инструментируйте обе стороны каждого postMessage метками времени. Измеряйте реальную латентность task-hop и стоимость клонирования в продакшене — local dev на быстрой машине систематически занижает и то, и другое.
• Отслеживайте длительность fetch-обработчика service worker. Медленный обработчик задерживает каждую навигацию и загрузку ресурсов страницы, и потому что он запускается до того, как главный поток видит ответ, регрессия там невидима для обычного main-thread профилирования.