DevNotes Live

Forwarded from Node.JS [ru] | Серверный JavaScript

⁣WeakRef и циклы: тихая утечка памяти в долгоживущих процессах

WeakRef в Node.js — инструмент для умных кэшей и подписок, но в долгоживущих серверных процессах он может стать причиной неочевидной утечки памяти. Самая распространенная ошибка — циклическая структура, где WeakRef замыкается с сильными ссылками, и GC молча перестает собирать объекты.

Как возникает утечка
В серверных приложениях часто используется дерево компонентов. Если дочерний элемент хранит WeakRef на родителя, а родитель — сильную ссылку на дочерний, цикл замкнут. GC видит, что объект родителя доступен через WeakRef, но сам WeakRef жив, и сборка блокируется. Результат — плавный рост heap, незаметный неделями.

Диагностика в production
- Снимайте heap snapshots через heapdump или Chrome DevTools. Ищите раздел System / WeakRef — там лежат недоступные объекты.
- Включайте --trace-gc и --trace-gc-verbose. Они покажут, какие объекты GC не может собрать из-за слабых ссылок.
- Мониторинг process.memoryUsage() и v8.getHeapStatistics() — кривая роста без видимых причин говорит о проблеме.

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

const registry = new FinalizationRegistry((held) => {
  console.log('cleaned', held);
});
class Child {
  constructor(parent) {
    this.parentWeakRef = new WeakRef(parent);
    registry.register(this, 'child');
  }
  getParent() {
    return this.parentWeakRef.deref();
  }
}

Ошибка, которую все допускают
WeakRef внутри замыкания на this — классика. Например, в WebSocket подписках: () => this.parent.someMethod сохраняет контекст с сильной ссылкой на весь граф. Всегда пишите явную проверку: this.parentWeakRef?.deref()?.someMethod. Иначе цикл восстановится.

Вывод: WeakRef — не панацея: в долгоживущих процессах всегда проверяйте цепочки замыканий и снимайте heap snapshots, иначе тихая утечка памяти станет причиной падения сервера.

1 view13:53