Шаблон наблюдателя WeakRef JavaScript: создание систем событий, учитывающих память

В мире современной веб-разработки одностраничные приложения (SPA) стали стандартом для создания динамичного и отзывчивого пользовательского опыта. Эти приложения часто работают в течение длительного времени, управляя сложным состоянием и обрабатывая бесчисленные взаимодействия с пользователем. Однако эта долговечность имеет скрытую цену: повышенный риск утечек памяти. Утечка памяти, когда приложение удерживает память, которая ему больше не нужна, со временем может ухудшить производительность, приводя к медлительности, сбоям браузера и ухудшению пользовательского опыта. Одним из наиболее распространенных источников этих утечек является фундаментальный шаблон проектирования: шаблон наблюдателя.

Шаблон наблюдателя является краеугольным камнем архитектуры, управляемой событиями, позволяя объектам (наблюдателям) подписываться и получать обновления от центрального объекта (субъекта). Он элегантный, простой и невероятно полезный. Но его классическая реализация имеет критический недостаток: субъект поддерживает жесткие ссылки на своих наблюдателей. Если наблюдатель больше не нужен остальной части приложения, но разработчик забывает явно отписать его от субъекта, он никогда не будет собран сборщиком мусора. Он остается в памяти, призрак, преследующий производительность вашего приложения.

Именно здесь современный JavaScript с его функциями ECMAScript 2021 (ES12) предоставляет мощное решение. Используя WeakRef и FinalizationRegistry, мы можем построить шаблон наблюдателя, учитывающий память, который автоматически очищает себя, предотвращая эти распространенные утечки. Эта статья представляет собой углубленный анализ этого передового метода. Мы рассмотрим проблему, поймем инструменты, создадим надежную реализацию с нуля и обсудим, когда и где этот мощный шаблон следует применять в ваших глобальных приложениях.

Понимание основной проблемы: классический шаблон наблюдателя и его использование памяти

Прежде чем мы сможем оценить решение, мы должны полностью понять проблему. Шаблон наблюдателя, также известный как шаблон издатель-подписчик, предназначен для разделения компонентов. Субъект (или издатель) поддерживает список своих зависимых, называемых наблюдателями (или подписчиками). Когда состояние субъекта изменяется, он автоматически уведомляет всех своих наблюдателей, как правило, вызывая определенный метод на них, например update().

Давайте рассмотрим простую классическую реализацию на JavaScript.

Простая реализация Subject

Вот базовый класс Subject. У него есть методы для подписки, отмены подписки и уведомления наблюдателей.

class ClassicSubject {

  constructor() {

    this.observers = [];

  }

 

  subscribe(observer) {

    this.observers.push(observer);

    console.log(`${observer.name} has subscribed.`);

  }

 

  unsubscribe(observer) {

    this.observers = this.observers.filter(obs => obs !== observer);

    console.log(`${observer.name} has unsubscribed.`);

  }

 

  notify(data) {

    console.log('Notifying observers...');

    this.observers.forEach(observer => observer.update(data));

  }

}

А вот простой класс Observer, который может подписаться на Subject.

class Observer {

  constructor(name) {

    this.name = name;

  }

 

  update(data) {

    console.log(`${this.name} received data: ${data}`);

  }

}

Скрытая опасность: сохраняющиеся ссылки

Эта реализация работает прекрасно, если мы тщательно управляем жизненным циклом наших наблюдателей. Проблема возникает, когда мы этого не делаем. Рассмотрим типичный сценарий в большом приложении: долгоживущее глобальное хранилище данных (Subject) и временный компонент пользовательского интерфейса (Observer), который отображает некоторые из этих данных.

Давайте смоделируем этот сценарий:

const dataStore = new ClassicSubject();

 

function manageUIComponent() {

  let chartComponent = new Observer('ChartComponent');

  dataStore.subscribe(chartComponent);

 

  // The component does its job...

 

  // Now, the user navigates away, and the component is no longer needed.

  // A developer might forget to add the cleanup code:

  // dataStore.unsubscribe(chartComponent);

 

  chartComponent = null; // We release our reference to the component.

}

 

manageUIComponent();

 

// Later in the application lifecycle...

dataStore.notify('New data available!');

В функции `manageUIComponent` мы создаем `chartComponent` и подписываем его на наш `dataStore`. Позже мы присваиваем `chartComponent` значение `null`, сигнализируя о том, что мы закончили с ним. Мы ожидаем, что сборщик мусора JavaScript (GC) увидит, что больше нет ссылок на этот объект, и освободит его память.

Но есть еще одна ссылка! Массив `dataStore.observers` по-прежнему содержит прямую, жесткую ссылку на объект `chartComponent`. Из-за этой единственной сохраняющейся ссылки сборщик мусора не может освободить память. Объект `chartComponent` и любые ресурсы, которые он содержит, останутся в памяти на протяжении всего жизненного цикла `dataStore`. Если это происходит повторно — например, каждый раз, когда пользователь открывает и закрывает модальное окно, — использование памяти приложением будет расти бесконечно. Это классическая утечка памяти.

Новая надежда: знакомство с WeakRef и FinalizationRegistry

ECMAScript 2021 представил две новые функции, специально разработанные для решения таких проблем управления памятью: `WeakRef` и `FinalizationRegistry`. Это продвинутые инструменты, которые следует использовать с осторожностью, но для нашей проблемы с шаблоном Observer они являются идеальным решением.

Что такое WeakRef?

Объект `WeakRef` содержит слабую ссылку на другой объект, называемый его целью. Ключевое различие между слабой ссылкой и обычной (жесткой) ссылкой заключается в следующем: слабая ссылка не мешает целевому объекту быть собранным сборщиком мусора.

Если единственными ссылками на объект являются слабые ссылки, механизм JavaScript может свободно уничтожить объект и освободить его память. Это именно то, что нам нужно для решения нашей проблемы с Observer.

Чтобы использовать `WeakRef`, вы создаете его экземпляр, передавая целевой объект в конструктор. Чтобы получить доступ к целевому объекту позже, вы используете метод `deref()`.

let targetObject = { id: 42 };

const weakRefToObject = new WeakRef(targetObject);

 

// To access the object:

const retrievedObject = weakRefToObject.deref();

 

if (retrievedObject) {

  console.log(`Object is still alive: ${retrievedObject.id}`); // Output: Object is still alive: 42

} else {

  console.log('Object has been garbage collected.');

}

Решающая часть заключается в том, что `deref()` может возвращать `undefined`. Это происходит, если `targetObject` был собран сборщиком мусора, потому что больше не существует жестких ссылок на него. Такое поведение является основой нашего шаблона Observer, учитывающего память.

Что такое FinalizationRegistry?

В то время как `WeakRef` позволяет собирать объект, он не дает нам чистого способа узнать, когда он был собран. Мы могли бы периодически проверять `deref()` и удалять результаты `undefined` из нашего списка наблюдателей, но это неэффективно. Именно здесь вступает в игру `FinalizationRegistry`.

`FinalizationRegistry` позволяет вам зарегистрировать функцию обратного вызова, которая будет вызвана после того, как зарегистрированный объект был собран сборщиком мусора. Это механизм для посмертной очистки.

Вот как это работает:

1. Вы создаете реестр с обратным вызовом очистки.
2. Вы `register()` объект с реестром. Вы также можете предоставить `heldValue`, который представляет собой фрагмент данных, который будет передан вашему обратному вызову при сборе объекта. Это `heldValue` не должно быть прямой ссылкой на сам объект, так как это сведет на нет цель!

// 1. Create the registry with a cleanup callback

const registry = new FinalizationRegistry(heldValue => {

  console.log(`An object has been garbage collected. Cleanup token: ${heldValue}`);

});

 

(function() {

  let objectToTrack = { name: 'Temporary Data' };

  let cleanupToken = 'temp-data-123';

 

  // 2. Register the object and provide a token for cleanup

  registry.register(objectToTrack, cleanupToken);

 

  // objectToTrack goes out of scope here

})();

 

// At some point in the future, after the GC runs, the console will log:

// "An object has been garbage collected. Cleanup token: temp-data-123"

Важные предостережения и лучшие практики

Прежде чем мы углубимся в реализацию, крайне важно понять природу этих инструментов. Поведение сборщика мусора в значительной степени зависит от реализации и недетерминировано. Это означает:

• Вы не можете предсказать, когда объект будет собран. Это может быть через секунды, минуты или даже дольше после того, как он станет недоступным.
• Вы не можете полагаться на то, что обратные вызовы `FinalizationRegistry` будут выполняться своевременно или предсказуемым образом. Они предназначены для очистки, а не для критической логики приложения.
• Чрезмерное использование `WeakRef` и `FinalizationRegistry` может усложнить рассуждения о коде. Всегда предпочитайте более простые решения (например, явные вызовы `unsubscribe`), если жизненные циклы объектов ясны и управляемы.

Эти функции лучше всего подходят для ситуаций, когда жизненный цикл одного объекта (наблюдателя) действительно независим от другого объекта (субъекта) и неизвестен ему.

Построение шаблона `WeakRefObserver`: пошаговая реализация

Теперь давайте объединим `WeakRef` и `FinalizationRegistry`, чтобы создать безопасный для памяти класс `WeakRefSubject`.

Шаг 1: структура класса `WeakRefSubject`

Наш новый класс будет хранить `WeakRef`s для наблюдателей вместо прямых ссылок. Он также будет иметь `FinalizationRegistry` для автоматической очистки списка наблюдателей.

class WeakRefSubject {

  constructor() {

    this.observers = new Set(); // Using a Set for easier removal

 

    // The finalizer callback. It receives the held value we provide during registration.

    // In our case, the held value will be the WeakRef instance itself.

    this.cleanupRegistry = new FinalizationRegistry(weakRefObserver => {

      console.log('Finalizer: An observer has been garbage collected. Cleaning up...');

      this.observers.delete(weakRefObserver);

    });

  }

}

Мы используем `Set` вместо `Array` для нашего списка наблюдателей. Это связано с тем, что удаление элемента из `Set` намного эффективнее (средняя временная сложность O(1)), чем фильтрация `Array` (O(n)), что будет полезно в нашей логике очистки.

Шаг 2: метод `subscribe`

Метод `subscribe` — это то, где начинается магия. Когда наблюдатель подписывается, мы:

1. Создайте `WeakRef`, который указывает на наблюдателя.
2. Добавьте этот `WeakRef` в наш набор `observers`.
3. Зарегистрируйте исходный объект наблюдателя в нашей `FinalizationRegistry`, используя вновь созданный `WeakRef` в качестве `heldValue`.

// Inside the WeakRefSubject class...

subscribe(observer) {

  // Check if an observer with this reference already exists

  for (const ref of this.observers) {

    if (ref.deref() === observer) {

      console.warn('Observer already subscribed.');

      return;

    }

  }

 

  const weakRefObserver = new WeakRef(observer);

  this.observers.add(weakRefObserver);

 

  // Register the original observer object. When it's collected,

  // the finalizer will be called with `weakRefObserver` as the argument.

  this.cleanupRegistry.register(observer, weakRefObserver);

 

  console.log('An observer has subscribed.');

}

Эта настройка создает умный цикл: субъект содержит слабую ссылку на наблюдателя. Реестр содержит жесткую ссылку на наблюдателя (внутри) до тех пор, пока он не будет собран сборщиком мусора. После сбора обратный вызов реестра запускается с экземпляром слабой ссылки, который мы затем можем использовать для очистки нашего набора `observers`.

Шаг 3: метод `unsubscribe`

Даже с автоматической очисткой мы все равно должны предоставить метод ручной `unsubscribe` для случаев, когда требуется детерминированное удаление. Этот метод должен будет найти правильный `WeakRef` в нашем наборе, разыменовывая каждый из них и сравнивая его с наблюдателем, которого мы хотим удалить.

// Inside the WeakRefSubject class...

unsubscribe(observer) {

  let refToRemove = null;

  for (const weakRef of this.observers) {

    if (weakRef.deref() === observer) {

      refToRemove = weakRef;

      break;

    }

  }

 

  if (refToRemove) {

    this.observers.delete(refToRemove);

    // IMPORTANT: We must also unregister from the finalizer

    // to prevent the callback from running unnecessarily later.

    this.cleanupRegistry.unregister(observer);

    console.log('An observer has unsubscribed manually.');

  }

}

Шаг 4: метод `notify`

Метод `notify` перебирает наш набор `WeakRef`s. Для каждого из них он пытается `deref()` его, чтобы получить фактический объект наблюдателя. Если `deref()` завершается успешно, это означает, что наблюдатель все еще активен, и мы можем вызвать его метод `update`. Если он возвращает `undefined`, наблюдатель был собран, и мы можем просто игнорировать его. `FinalizationRegistry` в конечном итоге удалит свой `WeakRef` из набора.

// Inside the WeakRefSubject class...

notify(data) {

  console.log('Notifying observers...');

  for (const weakRefObserver of this.observers) {

    const observer = weakRefObserver.deref();

    if (observer) {

      // The observer is still alive

      observer.update(data);

    } else {

      // The observer has been garbage collected.

      // The FinalizationRegistry will handle removing this weakRef from the set.

      console.log('Found a dead observer reference during notification.');

    }

  }

}

Объединяем все вместе: практический пример

Давайте вернемся к нашему сценарию компонента пользовательского интерфейса, но на этот раз, используя наш новый `WeakRefSubject`. Для простоты мы будем использовать тот же класс `Observer`, что и раньше.

// The same simple Observer class

class Observer {

  constructor(name) {

    this.name = name;

  }

  update(data) {

    console.log(`${this.name} received data: ${data}`);

  }

}

Теперь давайте создадим глобальную службу данных и смоделируем временный виджет пользовательского интерфейса.

const globalDataService = new WeakRefSubject();

function createAndDestroyWidget() {

  console.log('--- Creating and subscribing new widget ---');

  let chartWidget = new Observer('RealTimeChartWidget');

  globalDataService.subscribe(chartWidget);

 

  // The widget is now active and will receive notifications

  globalDataService.notify({ price: 100 });

 

  console.log('--- Destroying widget (releasing our reference) ---');

  // We are done with the widget. We set our reference to null.

  // We DO NOT need to call unsubscribe().

  chartWidget = null;

}

createAndDestroyWidget();

console.log('--- After widget destruction, before garbage collection ---');

globalDataService.notify({ price: 105 });

После запуска `createAndDestroyWidget()` объект `chartWidget` теперь ссылается только на `WeakRef` внутри нашего `globalDataService`. Поскольку это слабая ссылка, объект теперь имеет право на сборку мусора.

Когда сборщик мусора в конечном итоге запустится (что мы не можем предсказать), произойдут две вещи:

1. Объект `chartWidget` будет удален из памяти.
2. Будет запущен обратный вызов нашего `FinalizationRegistry`, который затем удалит теперь мертвый `WeakRef` из набора `globalDataService.observers`.

Если мы вызовем `notify` снова после того, как сборщик мусора запустится, вызов `deref()` вернет `undefined`, мертвый наблюдатель будет пропущен, и приложение продолжит эффективно работать без каких-либо утечек памяти. Мы успешно отделили жизненный цикл наблюдателя от субъекта.

Когда использовать (и когда избегать) шаблон `WeakRefObserver`

Этот шаблон мощный, но это не серебряная пуля. Он вводит сложность и полагается на недетерминированное поведение. Крайне важно знать, когда это правильный инструмент для работы.

Идеальные варианты использования

• Долгоживущие субъекты и недолговечные наблюдатели: это канонический вариант использования. Глобальная служба, хранилище данных или кэш (субъект), которые существуют на протяжении всего жизненного цикла приложения, в то время как многочисленные компоненты пользовательского интерфейса, временные работники или плагины (наблюдатели) создаются и уничтожаются часто.
• Механизмы кэширования: представьте себе кэш, который сопоставляет сложный объект с каким-либо вычисленным результатом. Вы можете использовать `WeakRef` для ключевого объекта. Если исходный объект собирается сборщиком мусора из остальной части приложения, `FinalizationRegistry` может автоматически очистить соответствующую запись в вашем кэше, предотвращая разбухание памяти.
• Архитектуры плагинов и расширений: если вы создаете основную систему, которая позволяет сторонним модулям подписываться на события, использование `WeakRefObserver` добавляет уровень отказоустойчивости. Это предотвращает неправильно написанный плагин, который забывает отписаться, от утечки памяти в вашем основном приложении.
• Сопоставление данных с элементами DOM: в сценариях без декларативной структуры вы можете захотеть связать некоторые данные с элементом DOM. Если вы сохраните это в карте с элементом DOM в качестве ключа, вы можете создать утечку памяти, если элемент удален из DOM, но все еще находится в вашей карте. `WeakMap` — лучший выбор, но принцип тот же: жизненный цикл данных должен быть привязан к жизненному циклу элемента, а не наоборот.

Когда придерживаться классического наблюдателя

• Тесно связанные жизненные циклы: если субъект и его наблюдатели всегда создаются и уничтожаются вместе или в одной и той же области, накладные расходы и сложность `WeakRef` не нужны. Простого, явного вызова `unsubscribe()` более удобно читать и предсказуемо.
• Критически важные горячие точки производительности: метод `deref()` имеет небольшую, но ненулевую стоимость производительности. Если вы уведомляете тысячи наблюдателей сотни раз в секунду (например, в игровом цикле или при визуализации данных высокой частоты), классическая реализация с прямыми ссылками будет быстрее.
• Простые приложения и скрипты: для небольших приложений или скриптов, где время жизни приложения короткое и управление памятью не является серьезной проблемой, классический шаблон проще реализовать и понять. Не добавляйте сложности там, где она не нужна.
• Когда требуется детерминированная очистка: если вам необходимо выполнить действие в точный момент, когда наблюдатель отсоединен (например, обновление счетчика, освобождение определенного аппаратного ресурса), вы должны использовать метод ручной `unsubscribe()`. Недетерминированный характер `FinalizationRegistry` делает его непригодным для логики, которая должна выполняться предсказуемо.

Более широкие последствия для архитектуры программного обеспечения

Введение слабых ссылок в язык высокого уровня, такой как JavaScript, сигнализирует о взрослении платформы. Это позволяет разработчикам создавать более сложные и устойчивые системы, особенно для долго работающих приложений. Этот шаблон поощряет сдвиг в архитектурном мышлении:

• Истинное разделение: оно обеспечивает уровень разделения, который выходит за рамки простого интерфейса. Теперь мы можем разделить сами жизненные циклы компонентов. Субъекту больше не нужно ничего знать о том, когда его наблюдатели создаются или уничтожаются.
• Устойчивость по дизайну: это помогает создавать системы, более устойчивые к ошибкам программиста. Забытый вызов `unsubscribe()` — распространенная ошибка, которую трудно отследить. Этот шаблон смягчает весь этот класс ошибок.
• Расширение возможностей авторов фреймворков и библиотек: для тех, кто создает фреймворки, библиотеки или платформы для других разработчиков, эти инструменты бесценны. Они позволяют создавать надежные API, которые менее подвержены неправильному использованию потребителями библиотеки, что приводит к более стабильным приложениям в целом.

Заключение: мощный инструмент для современного разработчика JavaScript

Классический шаблон Observer является фундаментальным строительным блоком разработки программного обеспечения, но его зависимость от жестких ссылок долгое время была источником тонких и неприятных утечек памяти в приложениях JavaScript. С появлением `WeakRef` и `FinalizationRegistry` в ES2021 у нас теперь есть инструменты для преодоления этого ограничения.

Мы прошли путь от понимания фундаментальной проблемы сохраняющихся ссылок до создания полностью учитывающего память `WeakRefSubject` с нуля. Мы видели, как `WeakRef` позволяет собирать объекты сборщиком мусора, даже когда за ними «наблюдают», и как `FinalizationRegistry` обеспечивает автоматический механизм очистки, чтобы поддерживать наш список наблюдателей в первозданном состоянии.

Однако с большой силой приходит большая ответственность. Это расширенные функции, недетерминированная природа которых требует тщательного рассмотрения. Они не заменяют хороший дизайн приложения и тщательное управление жизненным циклом. Но при применении к правильным проблемам — например, при управлении связью между долгоживущими сервисами и эфемерными компонентами — шаблон WeakRef Observer является исключительно мощным методом. Освоив его, вы можете писать более надежные, эффективные и масштабируемые приложения JavaScript, готовые удовлетворить потребности современного динамичного Интернета.