⁣Неявная блокировка Event Loop: как MapIterator убивает производительность в hot-path

Казалось бы, обычный for...of по Map — и вдруг Event Loop начинает тормозить. Проблема в скрытой аллокации MapIterator при деоптимизации V8. В hot-path это приводит к частому GC и блокировкам.

Почему это происходит
V8 в оптимизированном коде (TurboFan) может не аллоцировать итератор — он сохраняется на стеке или убирается escape analysis. Но деоптимизация из-за полиморфизма типов ключей (строки и числа), try/catch внутри цикла или превышения inline-лимитов заставляет создавать MapIterator в куче. В production это вызывает пинг-понг с GC.

Диагностика на практике
- --trace-gc — ищем аллокации MapIterator.
- --trace-deopt — смотрим причину: часто смешение типов ключей или нестабильный полиморфизм.
- Сравни for...of, map.forEach и ручной обход через Array.from(map.keys()) в бенчмарке. Разница может быть кратной.

Практический совет
В hot-path используй forEach, а не for...of. V8 может встроить его колбэк и избежать аллокации итератора. Если нужны ключи — закешируй их через Array.from и обходи обычным циклом.

Типичная ошибка
Не проверяешь стабильность типов ключей Map. Если ключи смешанные (строки и числа) — for...of гарантированно деоптимизируется. Зафиксируй типы или используй forEach.

Вывод: Аллокация MapIterator в hot-path из-за деоптимизации V8 — скрытая причина лагов Event Loop; замена for...of на map.forEach или кеширование ключей через Array.from устраняет проблему без ущерба для читаемости.

⁣structuredClone и Error с глубоким стек-трейсом: неявный убийца производительности в worker_threads

Передаёте Error через worker.postMessage()? Если стек-трейс глубокий — после цепочки асинхронных вызовов — V8 может незаметно блокировать поток на сериализации. Производительность падает линейно, а вы ищете причину в другом месте.

Почему это происходит

При вызове structuredClone V8 сериализует все перечислимые свойства объекта, включая .stack. Для Error с сотнями фреймов (длинные URL, аргументы функций) V8 парсит стековую строку целиком. Каждый фрейм проверяется, разбирается — и это происходит синхронно в вызывающем потоке. Пример: 5000 повторений .stack через repeat дают задержку ~100ms на postMessage.

Как диагностировать

Используйте --trace-event-categories или clinic flame. Ищите пики CPU в structuredClone. Сравните время postMessage с простым объектом против Error — разница в 10-50 раз при глубоком стеке. Типичная ошибка: разработчики грешат на дорогие вычисления, а на самом деле V8 тупо сериализует строчку.

Решение: не передавайте полный Error

Клонируйте только критичные поля: message, code, line, fileName. Для огромных стеков передавайте идентификатор ошибки, а полный стек собирайте локально. Можно упаковать Error в простой объект:

const safeError = {
  message: err.message,
  code: err.code,
  line: err.stack?.split('\n')[1]
};
worker.postMessage(safeError);

Production-кес: в нашем сервисе 20% CPU уходило на structuredClone ошибки с 1500+ фреймами. После замены на { msg: err.message } блокировка исчезла полностью.

Вывод: Не передавайте полный Error между воркерами при глубоких стеках — сериализация через structuredClone может незаметно съедать 10-20% CPU и блокировать поток.

⁣Диагностика и устранение неявного замедления TLS-рукопожатий из-за скрытой конкуренции за entropy pool в кластеризованных HTTPS-серверах

Если вы держите Node.js в кластере — через PM2 или встроенный cluster, — могли замечать странные задержки при HTTPS-соединениях. Вроде всё настроено, а рукопожатия то 5 мс, то 500+. Одна из неочевидных причин — драка за entropy pool.

Причина
Внутри каждого TLS-рукопожатия Node.js дёргает случайные числа для ключей. В Linux это /dev/urandom или getrandom(). Когда несколько воркеров одновременно лезут в один пул энтропии, начинаются блокировки. Особенно в контейнерах без аппаратного RNG — там стекло быстро заканчивается.

Симптомы: время рукопожатия плавает хаотично, иногда blocked for more than 120 seconds. strace покажет, что провал в crypto.randomFill().

Диагностика
Берите strace -e trace=getrandom -p <PID> -o entropy.log. Если вызовы висят дольше 1 мс — проблема. Проверьте скорость энтропии: dd if=/dev/urandom bs=1024 count=100 | pv.

Решения
* Отдельный seed для каждого воркера. При старте слать его через IPC из master:

process.on('message', (msg) => {
  if (msg.type === 'seed') {
    global._seed = msg.seed;
  }
});

* Для операций после старта — только асинхронный crypto.randomFill с callback. Синхронный вызов дёргает блокировку пула.
* На bare-metal поставьте haveged или rng-tools, в облаке — virtio-rng.

Типичная ошибка
Не используйте Math.random() для криптографии — это антипаттерн, который не решает проблему, а только создаёт уязвимости.

Вывод: Диагностика через strace и управление seed-ами — эффективный способ ускорить TLS без переписывания стека, но критично проверить нагрузку на entropy pool в кластере с 10+ воркерами.

⁣Скрытая утечка памяти: когда WeakRef и Symbol.dispose убивают DI-контейнер

В long-lived DI-контейнерах циклические зависимости в сочетании с WeakRef и Symbol.dispose создают неочевидную проблему: коллбэки очистки замыкают целые графы объектов, превращая WeakRef в бессмысленный инструмент. Разработчики часто доверяют GC, не замечая, что память не освобождается годами.

Как возникает теневая связность
Когда вы регистрируете коллбэк в WeakMap на основе WeakRef, замыкание захватывает dispose-функцию, которая тянет весь service-граф. Даже если WeakRef.deref() возвращает undefined, ссылка в замыкании удерживает объекты. Они становятся "полуживыми" - не имеют сильных ссылок, но GC их не собирает из-за скрытой цепочки через dispose.

Диагностика в production
Запуск с --expose-gc и global.gc() не покажет освобождения. Heap snapshot в Chrome DevTools обнаружит объекты без явных strong references, но присутствующие в WeakMap. Это сигнал, что проблема в замыканиях коллбэков. Типичная ошибка: проверка только первого уровня графа.

Решение 1: точечное замыкание
Вместо передачи всего service в коллбэк берите только метод через bind:

const handler = service[Symbol.dispose]?.bind(service);

Это разрывает неявную связь с полным графом.

Решение 2: FinalizationRegistry
Он не удерживает ссылку на объект. Регистрируете коллбэк с heldValue, который не ссылается на service:

const registry = new FinalizationRegistry((heldValue) => {});
registry.register(service, cleanupToken, token);

Решение 3: отказ от WeakRef при циклах
Для циклических зависимостей используйте reference counting в пуле синглтонов. Надёжнее, хоть и менее элегантно:

class RefCountPool {
  private refs = new Map();
  acquire(key) { this.refs.set(key, (this.refs.get(key) || 0) + 1); }
  release(key) { if (this.refs.get(key) === 1) this.refs.delete(key); }
}

Вывод: WeakRef не гарантирует безопасной очистки при наличии замыканий в коллбэках, поэтому всегда профилируйте память в циклах зависимости и используйте FinalizationRegistry или reference counting для long-lived контейнеров.

⁣Неявный рассинхрон состояния при AsyncLocalSnapshot, EventEmitter и Symbol.asyncDispose

Работаете с распределёнными очередями задач? Тогда наверняка сталкивались с AsyncLocalStorage для проброса контекста. Но связка AsyncLocalSnapshot с EventEmitter и забытый Symbol.asyncDispose приводят к багу, который воспроизводится раз на 50 запусков — контекст устаревает, состояние утекает.

Почему контекст утекает
AsyncLocalSnapshot замораживает контекст при создании, но колбэк от EventEmitter может жить дольше задачи. Если слушатель не удалён, он выполняется с устаревшим состоянием. В production это даёт stale data — задача обрабатывается с контекстом предыдущей или undefined.

Production-пример ошибки
Типичный сценарий: воркер запускает задачу, подписывается на события прогресса через emitter.on, но не чистит слушатель. В итоге в следующей задаче AsyncLocalSnapshot возвращает старый контекст. Код:

const snapshot = new AsyncLocalSnapshot(als);
emitter.on('event', snapshot.run(data => {
  console.log(als.getStore()); // устаревший контекст
}));
// Слушатель не удалён — баг

Типичная ошибка
Забывают реализовать Symbol.asyncDispose для временных слушателей. Или создают снапшот вне обработчика, вместо того чтобы делать это внутри. Совет: всегда используйте try/finally для очистки подписок.

Практический совет
Для долгоживущих слушателей не используйте AsyncLocalSnapshot — сохраняйте контекст в замыкании. Если нужно, чистите через finally или Symbol.asyncDispose:

class Worker {
  async [Symbol.asyncDispose]() {
    emitter.removeAllListeners('progress');
  }
}

Вывод: Управляйте временем жизни подписок явно — AsyncLocalSnapshot это моментальный снимок, а не долгоживущий контекст.

⁣Неявное зависание Promise.all при отмене AsyncIterator через AbortController

Вы используете for await...of с асинхронным генератором и AbortController для отмены. Кажется, всё чисто, но Promise.all зависает намертво. Проблема в том, что вызов abort() вызывает return() генератора, но если внутри остался незавершённый промис (таймер, подписка, поток), он просто висит, и Promise.all никогда не завершится.

Как возникает утечка
Когда abort() срабатывает внутри for await...of, итератор завершается. Но если в генераторе есть запущенный, но не завершённый setInterval, await на потоке данных или подписка на событие, этот промис остаётся висеть в памяти. Например, генератор каждую секунду отправляет данные, а при abort обработчик завершает итерацию, но не очищает таймер. Promise.all ждёт этот таймер вечно.

Диагностика на практике
Добавьте в конец return() генератора console.log('return called'). Если return вызывается, а Promise.all не завершается — ищите, какой ресурс утекает. Используйте обёртку с таймаутом: Promise.race([Promise.all(...), AbortSignal.timeout(5000)]). В продакшне это спасёт от вечного ожидания, но не решит корень проблемы.

Совет по исправлению
Всегда оборачивайте тело асинхронного генератора в try/finally. В finally явно очищайте все ресурсы: удаляйте слушатели, отменяйте таймеры, разрешайте ожидающие промисы. Например, если внутри генератора есть setInterval:

async function* gen(signal) {
  const timer = setInterval(() => {}, 1000);
  try {
    while (!signal.aborted) {
      await new Promise(r => setTimeout(r, 100));
      yield data;
    }
  } finally {
    clearInterval(timer);
  }
}

Вывод: Каждый yield и await в асинхронном генераторе должен быть гарантированно завершён до конца итерации, иначе return() не прервёт внутренние промисы, что приведёт к невосстанавливаемому зависанию.

Как получить оффер в Яндекс, Сбер, МТС и другие крутые компании?

На фото ребята из моего комьюнити, где уже больше 220 frontend-разработчиков. Все они успешно устроились в крутые компании и получили офферы от 300 тыс рублей 🫂

👋 Привет, меня зовут Тихон, я действующий Frontend-разработчик и ментор. За руку довожу до оффера в Big Tech и остаюсь рядом на испытательном сроке.

В их жизни больше нет бесконечных скучных созвонов, безуспешных откликов на вакансии, странноватых собесов с вопросами словно ты на олимпиаде.

И у тебя тоже получится 😎

У меня есть канал, где я:
👉 Показываю, как пройти HR-фильтр и превратить отклики в реальные приглашения
👉 Помогаю найти мотивацию и разбираюсь с убеждениями, которые мешают расти
👉 На примерах показываю, как проходить собеседования, включая техничку
👉 Разбираю резюме и делюсь лайфхаками — например, как аккуратно «пинговать» рекрутеров

И регулярно выкладываю полезное:
▪️ Задачи, на которых валятся кандидаты
▪️ Подборка из 100+ каналов с вакансиями для разработчиков
▪️ 100 вопросов, которые помогут тебе на собеседовании
▪️ Чек-лист для проверки своего резюме

Подписывайся: https://t.me/+KcX6eD0fuRY3M2Uy

Реклама, erid: 2W5zFJKcvZP ИП Галактионов Тихон Витальевич, ИНН 771618975809