Шаблон Спостерігача JavaScript WeakRef: Побудова Систем Сповіщень, Свідомих Пам'яті

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

Шаблон спостерігача є наріжним каменем архітектури, керованої подіями, що дозволяє об'єктам (спостерігачам) підписуватися на оновлення від центрального об'єкта (суб'єкта) та отримувати їх. Він елегантний, простий і неймовірно корисний. Але його класична реалізація має критичний недолік: суб'єкт утримує сильні посилання на своїх спостерігачів. Якщо спостерігач більше не потрібен іншим частинам програми, але розробник забув явно відписати його від суб'єкта, він ніколи не буде зібраний збирачем сміття. Він залишається замкненим у пам'яті, привидом, що переслідує продуктивність вашого додатка.

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

Розуміння Основної Проблеми: Класичний Шаблон Спостерігача та Його Обсяг Пам'яті

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

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

Проста Реалізація Суб'єкта

Ось базовий клас Суб'єкта. Він має методи для підписки, відписки та сповіщення спостерігачів.

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));

  }

}

І ось простий клас Спостерігача, який може підписатися на Суб'єкта.

class Observer {

  constructor(name) {

    this.name = name;

  }

 

  update(data) {

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

  }

}

Прихована Небезпека: Залишкові Посилання

Ця реалізація працює ідеально, поки ми сумлінно керуємо життєвим циклом наших спостерігачів. Проблема виникає, коли ми цього не робимо. Розглянемо типовий сценарій у великому додатку: довгоживуче глобальне сховище даних (Суб'єкт) та тимчасовий компонент інтерфейсу користувача (Спостерігач), який відображає частину цих даних.

Спробуємо змоделювати цей сценарій:

const dataStore = new ClassicSubject();

 

function manageUIComponent() {

  let chartComponent = new Observer('ChartComponent');

  dataStore.subscribe(chartComponent);

 

  // Компонент виконує свою роботу...

 

  // Тепер користувач переходить до іншої сторінки, і компонент більше не потрібен.

  // Розробник може забути додати код очищення:

  // dataStore.unsubscribe(chartComponent);

 

  chartComponent = null; // Ми випускаємо наше посилання на компонент.

}

 

manageUIComponent();

 

// Пізніше в життєвому циклі додатка...

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

У функції `manageUIComponent` ми створюємо `chartComponent` і підписуємо його до нашого `dataStore`. Пізніше ми встановлюємо `chartComponent` на `null`, сигналізуючи, що ми закінчили його використання. Ми очікуємо, що збирач сміття JavaScript (GC) побачить, що більше немає посилань на цей об'єкт, і звільнить його пам'ять.

Але є ще одне посилання! Масив `dataStore.observers` все ще містить пряме, сильне посилання на об'єкт `chartComponent`. Через це одне залишене посилання збирач сміття не може звільнити пам'ять. Об'єкт `chartComponent` та будь-які ресурси, які він утримує, залишаться в пам'яті протягом усього терміну життя `dataStore`. Якщо це відбувається неодноразово — наприклад, щоразу, коли користувач відкриває та закриває модальне вікно — використання пам'яті додатком буде зростати нескінченно. Це класичний витік пам'яті.

Нова Надія: Представлення WeakRef та FinalizationRegistry

ECMAScript 2021 представив дві нові функції, спеціально розроблені для вирішення таких завдань управління пам'яттю: `WeakRef` та `FinalizationRegistry`. Це передові інструменти, і їх слід використовувати обережно, але для нашої проблеми шаблону спостерігача вони є ідеальним рішенням.

Що таке WeakRef?

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

Якщо єдиними посиланнями на об'єкт є слабкі посилання, механізм JavaScript може вільно знищити об'єкт і звільнити його пам'ять. Це саме те, що нам потрібно для вирішення нашої проблеми спостерігача.

Щоб використовувати `WeakRef`, ви створюєте його екземпляр, передаючи цільовий об'єкт до конструктора. Щоб отримати доступ до цільового об'єкта пізніше, ви використовуєте метод `deref()`.

let targetObject = { id: 42 };

const weakRefToObject = new WeakRef(targetObject);

 

// Щоб отримати доступ до об'єкта:

const retrievedObject = weakRefToObject.deref();

 

if (retrievedObject) {

  console.log(`Object is still alive: ${retrievedObject.id}`); // Вивід: Object is still alive: 42

} else {

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

}

Критично важлива частина полягає в тому, що `deref()` може повернути `undefined`. Це відбувається, якщо `targetObject` був зібраний збирачем сміття, оскільки до нього більше не існує сильних посилань. Ця поведінка є основою нашого свідомого до пам'яті шаблону спостерігача.

Що таке FinalizationRegistry?

Хоча `WeakRef` дозволяє об'єкту бути зібраним, він не надає нам чіткого способу дізнатися, коли він був зібраний. Ми могли б періодично перевіряти `deref()` і видаляти `undefined` результати з нашого списку спостерігачів, але це неефективно. Саме тут з'являється `FinalizationRegistry`.

`FinalizationRegistry` дозволяє зареєструвати функцію зворотного виклику, яка буде викликана після того, як зареєстрований об'єкт буде зібраний збирачем сміття. Це механізм для очищення після смерті.

Ось як це працює:

1. Ви створюєте реєстр із функцією очищення.
2. Ви `register()` об'єкт у реєстрі. Ви також можете надати `heldValue`, яке є шматком даних, що буде передано до вашої функції зворотного виклику, коли об'єкт буде зібраний. Це `heldValue` не повинно бути прямим посиланням на сам об'єкт, оскільки це зведе нанівець мету!

// 1. Створіть реєстр із функцією очищення

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. Зареєструйте об'єкт і надайте токен для очищення

  registry.register(objectToTrack, cleanupToken);

 

  // objectToTrack виходить із області видимості тут

})();

 

// У певний момент у майбутньому, після запуску GC, консоль виведе:

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

Важливі Застереження та Найкращі Практики

Перш ніж ми зануримося в реалізацію, вкрай важливо зрозуміти природу цих інструментів. Поведінка збирача сміття значною мірою залежить від реалізації та є недетермінованою. Це означає:

• Ви не можете передбачити, коли об'єкт буде зібраний. Це може бути через секунди, хвилини або навіть довше після того, як він стане недосяжним.
• Ви не можете покладатися на те, що функції зворотного виклику `FinalizationRegistry` будуть виконуватися вчасно або передбачувано. Вони призначені для очищення, а не для критично важливої логіки програми.
• Надмірне використання `WeakRef` та `FinalizationRegistry` може ускладнити розуміння коду. Завжди віддавайте перевагу простішим рішенням (як явні виклики `unsubscribe`), якщо життєві цикли об'єктів чіткі та керовані.

Ці функції найкраще підходять для ситуацій, коли життєвий цикл одного об'єкта (спостерігача) справді незалежний від іншого об'єкта (суб'єкта) і невідомий йому.

Побудова Шаблону `WeakRefObserver`: Покрокова Реалізація

Тепер поєднаємо `WeakRef` та `FinalizationRegistry`, щоб створити безпечний щодо пам'яті клас `WeakRefSubject`.

Крок 1: Структура Класу `WeakRefSubject`

Наш новий клас буде зберігати `WeakRef` спостерігачів замість прямих посилань. Він також матиме `FinalizationRegistry` для обробки автоматичного очищення списку спостерігачів.

class WeakRefSubject {

  constructor() {

    this.observers = new Set(); // Використовуємо Set для легшого видалення

 

    // Функція зворотного виклику фіналізатора. Вона отримує значення, яке ми надаємо під час реєстрації.

    // У нашому випадку значенням буде сам екземпляр WeakRefObserver.

    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`.

// Всередині класу WeakRefSubject...

subscribe(observer) {

  // Перевірити, чи вже існує спостерігач з цим посиланням

  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);

 

  // Зареєструвати оригінальний об'єкт спостерігача. Коли він буде зібраний,

  // функція зворотного виклику фіналізатора буде викликана з `weakRefObserver` як аргументом.

  this.cleanupRegistry.register(observer, weakRefObserver);

 

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

}

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

Крок 3: Метод `unsubscribe`

Навіть з автоматичним очищенням, ми повинні надати ручний метод `unsubscribe` для випадків, коли потрібне детерміноване видалення. Цей метод повинен буде знайти відповідний `WeakRef` у нашому наборі, розіменувавши кожен і порівнявши його зі спостерігачем, який ми хочемо видалити.

// Всередині класу WeakRefSubject...

unsubscribe(observer) {

  let refToRemove = null;

  for (const weakRef of this.observers) {

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

      refToRemove = weakRef;

      break;

    }

  }

 

  if (refToRemove) {

    this.observers.delete(refToRemove);

    // ВАЖЛИВО: Ми також повинні відкликати реєстрацію з фіналізатора

    // щоб запобігти непотрібному виклику функції зворотного виклику пізніше.

    this.cleanupRegistry.unregister(observer);

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

  }

}

Крок 4: Метод `notify`

Метод `notify` ітерує по нашому набору `WeakRef`. Для кожного він намагається викликати `deref()`, щоб отримати фактичний об'єкт спостерігача. Якщо `deref()` успішний, це означає, що спостерігач ще живий, і ми можемо викликати його метод `update`. Якщо він повертає `undefined`, спостерігач був зібраний, і ми можемо просто проігнорувати його. `FinalizationRegistry` з часом видалить його `WeakRef` з набору.

// Всередині класу WeakRefSubject...

notify(data) {

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

  for (const weakRefObserver of this.observers) {

    const observer = weakRefObserver.deref();

    if (observer) {

      // Спостерігач ще живий

      observer.update(data);

    } else {

      // Спостерігач був зібраний збирачем сміття.

      // FinalizationRegistry обробить видалення цього weakRef з набору.

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

    }

  }

}

Зводимо Все Докупи: Практичний Приклад

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

// Той самий простий клас Observer

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);

 

  // Віджет тепер активний і буде отримувати сповіщення

  globalDataService.notify({ price: 100 });

 

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

  // Ми закінчили з віджетом. Ми встановлюємо наше посилання на null.

  // Нам НЕ ПОТРІБНО викликати 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 Розробника

Класичний шаблон спостерігача є фундаментальним будівельним блоком проектування програмного забезпечення, але його залежність від сильних посилань довго була джерелом тонких і дратівливих витоків пам'яті в JavaScript-додатках. З появою `WeakRef` та `FinalizationRegistry` в ES2021, ми тепер маємо інструменти для подолання цього обмеження.

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

Однак, велика сила приходить з великою відповідальністю. Це передові функції, чия недетермінована природа вимагає ретельного розгляду. Вони не є заміною хорошого дизайну програми та сумлінного управління життєвим циклом. Але коли вони застосовуються до правильних завдань — таких як управління комунікацією між довгоживучими службами та ефемерними компонентами — шаблон WeakRef Observer є винятково потужною технікою. Оволодівши ним, ви можете писати більш стійкі, ефективні та масштабовані JavaScript-додатки, готові відповідати вимогам сучасної, динамічної мережі.