⁣Диагностика и устранение deferred reference cycles в WeakRef и FinalizationRegistry: кэши и пулы в долгоживущих процессах

С WeakRef и FinalizationRegistry в Node.js можно получить скрытые утечки памяти, когда объекты в кэшах и пулах соединений не освобождаются из-за циклических ссылок через cleanup-функции. В production это проявляется как постепенный рост heap в долгоживущих процессах.

Ловушка deferred cycles
Основная проблема - передача объекта (например, socket) в FinalizationRegistry как heldValue внутри cleanup-функции, которая замыкается на тот же объект. Пока cleanup висит в очереди, GC не может освободить объект, так как registry его удерживает.

const registry = new FinalizationRegistry((heldValue) => {
  heldValue.socket.destroy();
});

class CachedConnection {
  constructor(socket) {
    this.socket = socket;
    registry.register(this, this); // цикл: this как heldValue
  }
}

Диагностика
- Используй heap snapshots через --inspect: ищи цепочку WeakRef -> Object -> FinalizationRegistry
- Следи за process.memoryUsage().heapUsed при простое - рост без причины признак deferred cycle
- Логируй вызовы FinalizationRegistry: если cleanup не происходит после удаления всех внешних ссылок, цикл активен

Production-ориентированный совет
Для пулов соединений храни только идентификаторы в WeakRef, а реальные объекты - в отдельном Map с таймаутом.

registry.register(this, this.socket.id); // примитив, разрывает цикл

Или используй явную отписку:

registry.unregister(this) // перед удалением ссылки

Типичная ошибка
Передача в registry объекта с методами, которые держат ссылки на другие ресурсы. Это создает неявные циклы, которые GC не распознает.

Вывод: Deferred reference cycles - это скрытые утечки, которые требует диагностики через heap snapshots и разрыва замыканий через примитивы в FinalizationRegistry.

Фича в портфолио, которую почти никто не делает — хотя все хотят выделиться

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

Читать на дизайнерс | #Карьера #Продуктовыйдизайн

Приложение для управления бизнесом и его финансами

Категория: #финансы
Язык: #en

https://dribbble.com/shots/17897645-Finance-Dark-theme-Design

Изучите ИИ за несколько вечеров — и начните делать работу вдвое быстрее

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

На бесплатном мини-курсе вы научитесь:
— Делать свою работу быстрее
— Делегировать ИИ тексты, аналитику и маркетинг
— Автоматизировать рутинные задачи
— Расти в профессии и карьере

Без сложного кода и бесконечной теории — только практика, мини-проекты и быстрые результаты. Переходите по ссылке и регистрируйтесь бесплатно.

Реклама. Информация о рекламодателе по ссылкам в посте.

📖AI for Everyday IT
🖋Abshire Brandon, LeMaire Chrissy 2025

Что, если бы вам больше никогда не приходилось писать отчеты об инцидентах, шаблонный код или аналитические обзоры с нуля? Используйте инструменты на основе искусственного интеллекта, такие как ChatGPT, Claude, Gemini и Copilot, и вы сэкономите себе часы времени, а то и больше! AI for Everyday IT рассказывает, как с помощью генеративного искусственного интеллекта автоматизировать десятки повседневных ИТ-задач.

💾 Скачать книгу

Daily Coding #книги #AI & Max

Фирменный стиль архитектурной компании Paper Igloo от студии Need.

#брендинг #архитектура_интерьер

⁣Как temporal.io SDK ломает V8 heap snapshot в длительных Workflow

Если ваш Workflow Execution живёт неделями, готовьтесь к сюрпризам: V8 перестаёт адекватно собирать мусор, а heap snapshot превращается в помойку из ретейнеров. Частая ошибка — считать, что GC справится сам, но Temporal SDK активно мешает ему.

Почему GC не работает
SDK держит один V8 isolate на весь Worker. Пока Workflow крутится, Temporal сохраняет историю состояний и коллбэки. V8 честно чистит память, но SDK не даёт объектам уйти через замыкания в таймерах и маппингах. WeakRef и FinalizationRegistry в детерминированном коде — отдельная боль: GC просто не видит, что объекты уже никому не нужны. В результате в heap зависают ретейнеры вроде WorkflowContext и ActivityContext.

Production-кейс: Map на миллион элементов
Пишете долгий воркфлоу с Map на миллион элементов, потом ставите Workflow.sleep('1 year'). Этот Map останется в памяти до перезапуска воркера. Почему: SDK замораживает каждое состояние через Object.freeze(), и ссылки на объекты в V8 heap остаются. V8 считает их живыми, пока isolate жив — heap аккумулируется, RSS ползёт вверх, GC тормозит.

Практические советы
* Обновляйтесь до @temporalio/workflow >=1.8.0 — там появился явный context.reset().
* Чистите Map и Set руками: largeMap.clear().
* Дёргайте maxWorkflowCachedExecution, чтобы принудительно пересоздавать isolate.
* Мониторьте heap через process.memoryUsage() и рестартуйте Worker, если память перевалила за лимит.

Вывод: В длительных Workflow явное управление памятью важнее надежды на GC — закладывайте очистку структур данных и рестарты Worker в архитектуру с самого начала.