Моделът Observer с WeakRef в JavaScript: Изграждане на системи за събития, осъзнаващи паметта

В света на модерното уеб разработване, едностраничните приложения (SPAs) се превърнаха в стандарт за създаване на динамични и отзивчиви потребителски изживявания. Тези приложения често работят за продължителни периоди, управлявайки сложно състояние и обработвайки безброй потребителски взаимодействия. Тази дълготрайност обаче идва със скрита цена: повишения риск от течове на памет. Изтичането на памет, при което едно приложение задържа памет, от която вече не се нуждае, може да влоши производителността с течение на времето, което да доведе до забавяне, сривове на браузъра и лошо потребителско изживяване. Един от най-честите източници на тези течове се крие в основен модел на проектиране: моделът Observer.

Моделът Observer е крайъгълен камък на архитектурата, задвижвана от събития, позволяваща на обекти (наблюдатели) да се абонират и да получават актуализации от централен обект (субекта). Той е елегантен, прост и изключително полезен. Но неговата класическа реализация има критичен недостатък: субектът поддържа силни препратки към своите наблюдатели. Ако един наблюдател вече не е необходим за останалата част от приложението, но разработчикът забрави изрично да го отпише от субекта, той никога няма да бъде събран от сборчика за отпадъци. Той остава в капан в паметта, призрак, преследващ производителността на вашето приложение.

Тук модерният JavaScript, със своите ECMAScript 2021 (ES12) функции, предоставя мощно решение. Чрез използването на WeakRef и FinalizationRegistry, можем да изградим Observer модел, осъзнаващ паметта, който автоматично се почиства сам, предотвратявайки тези често срещани течове. Тази статия е задълбочено потапяне в тази напреднала техника. Ще разгледаме проблема, ще разберем инструментите, ще изградим стабилна реализация от нулата и ще обсъдим кога и къде този мощен модел трябва да се прилага във вашите глобални приложения.

Разбиране на основния проблем: Класическият Observer модел и неговият отпечатък в паметта

Преди да можем да оценим решението, трябва напълно да разберем проблема. Моделът Observer, известен също като модел Publisher-Subscriber, е проектиран да развързва компоненти. Един Subject (или Publisher) поддържа списък от своите зависими, наречени Observers (или Subscribers). Когато състоянието на Subject се промени, той автоматично уведомява всички свои Observers, обикновено като извика специфичен метод върху тях, като например update().

Нека разгледаме една проста, класическа реализация в JavaScript.

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

Ето един основен клас Subject. Той има методи за абониране, отписване и уведомяване на наблюдатели.

class ClassicSubject {

  constructor() {

    this.observers = [];

  }

 

  subscribe(observer) {

    this.observers.push(observer);

    console.log(`${observer.name} се абонира.`);

  }

 

  unsubscribe(observer) {

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

    console.log(`${observer.name} се отписа.`);

  }

 

  notify(data) {

    console.log('Уведомяване на наблюдатели...');

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

  }

}

И ето един прост клас Observer, който може да се абонира за Subject.

class Observer {

  constructor(name) {

    this.name = name;

  }

 

  update(data) {

    console.log(`${this.name} получи данни: ${data}`);

  }

}

Скритата опасност: Остатъчни препратки

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

Нека симулираме този сценарий:

const dataStore = new ClassicSubject();

 

function manageUIComponent() {

  let chartComponent = new Observer('ChartComponent');

  dataStore.subscribe(chartComponent);

 

  // Компонентът си върши работата...

 

  // Сега потребителят напуска страницата и компонентът вече не е нужен.

  // Разработчик може да забрави да добави код за почистване:

  // dataStore.unsubscribe(chartComponent);

 

  chartComponent = null; // Освобождаваме нашата препратка към компонента.

}

 

manageUIComponent();

 

// По-късно в жизнения цикъл на приложението...

dataStore.notify('Налични са нови данни!');

Във функцията `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);

 

// За достъп до обекта:

const retrievedObject = weakRefToObject.deref();

 

if (retrievedObject) {

  console.log(`Обектът е все още жив: ${retrievedObject.id}`); // Изход: Обектът е все още жив: 42

} else {

  console.log('Обектът е събран от сборчика за отпадъци.');

}

Ключовата част е, че `deref()` може да върне `undefined`. Това се случва, ако `targetObject` е бил събран от сборчика за отпадъци, защото вече не съществуват силни препратки към него. Това поведение е основата на нашия Observer модел, осъзнаващ паметта.

Какво е FinalizationRegistry?

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

Един `FinalizationRegistry` ви позволява да регистрирате callback функция, която ще бъде извикана след като регистриран обект е бил събран от сборчика за отпадъци. Това е механизъм за почистване след смъртта.

Ето как работи:

1. Създавате регистър с callback за почистване.
2. Регистрирате (`register()`) обект в регистъра. Можете също така да предоставите `heldValue`, което е част от данни, които ще бъдат предадени на вашия callback, когато обектът бъде събран. Този `heldValue` не трябва да бъде пряка препратка към самия обект, тъй като това би обезсмислило целта!

// 1. Създайте регистъра с callback за почистване

const registry = new FinalizationRegistry(heldValue => {

  console.log(`Обект е събран от сборчика за отпадъци. Токен за почистване: ${heldValue}`);

});

 

(function() {

  let objectToTrack = { name: 'Временни данни' };

  let cleanupToken = 'temp-data-123';

 

  // 2. Регистрирайте обекта и предоставете токен за почистване

  registry.register(objectToTrack, cleanupToken);

 

  // objectToTrack излиза от обхват тук

})();

 

// В някакъв момент в бъдещето, след като GC се изпълни, конзолата ще отпечата:

// "Обект е събран от сборчика за отпадъци. Токен за почистване: temp-data-123"

Важни уговорки и най-добри практики

Преди да се потопим в реализацията, е от решаващо значение да разберем естеството на тези инструменти. Поведението на сборчика за отпадъци е силно зависимо от реализацията и не е детерминистично. Това означава:

• Вие не можете да предвидите кога обект ще бъде събран. Това може да отнеме секунди, минути или дори повече, след като стане недостижим.
• Вие не можете да разчитате на callback функциите на `FinalizationRegistry` да се изпълняват своевременно или предсказуемо. Те са за почистване, а не за критична логика на приложението.
• Злоупотребата с `WeakRef` и `FinalizationRegistry` може да затрудни разбирането на кода. Винаги предпочитайте по-прости решения (като изрични извиквания на `unsubscribe`), ако жизнените цикли на обектите са ясни и управляеми.

Тези функции са най-подходящи за ситуации, в които жизненият цикъл на един обект (наблюдателя) е наистина независим от и неизвестен на друг обект (субекта).

Изграждане на модела `WeakRefObserver`: Реализация стъпка по стъпка

Сега, нека комбинираме `WeakRef` и `FinalizationRegistry`, за да изградим клас `WeakRefSubject`, който е безопасен за паметта.

Стъпка 1: Структурата на класа `WeakRefSubject`

Нашият нов клас ще съхранява `WeakRef` към наблюдатели вместо преки препратки. Той също така ще има `FinalizationRegistry` за автоматично почистване на списъка с наблюдатели.

class WeakRefSubject {

  constructor() {

    this.observers = new Set(); // Използване на Set за по-лесно премахване

 

    // Callback функцията на финализатора. Тя получава запазената стойност, която предоставяме по време на регистрация.

    // В нашия случай, запазената стойност ще бъде самият WeakRef екземпляр.

    this.cleanupRegistry = new FinalizationRegistry(weakRefObserver => {

      console.log('Финализатор: Наблюдател е събран от сборчика за отпадъци. Почистване...');

      this.observers.delete(weakRefObserver);

    });

  }

}

Използваме `Set` вместо `Array` за нашия списък с наблюдатели. Това е така, защото изтриването на елемент от `Set` е много по-ефективно (средна времева сложност O(1)) от филтрирането на `Array` (O(n)), което ще бъде полезно в нашата логика за почистване.

Стъпка 2: Методът `subscribe`

Методът `subscribe` е мястото, където започва магията. Когато един наблюдател се абонира, ние ще:

1. Създадем `WeakRef`, който сочи към наблюдателя.
2. Добавим този `WeakRef` към нашия `observers` set.
3. Регистрираме оригиналния обект на наблюдателя с нашия `FinalizationRegistry`, използвайки новосъздадения `WeakRef` като `heldValue`.

// Вътре в класа WeakRefSubject...

subscribe(observer) {

  // Проверете дали наблюдател с тази препратка вече съществува

  for (const ref of this.observers) {

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

      console.warn('Наблюдателят вече е абониран.');

      return;

    }

  }

 

  const weakRefObserver = new WeakRef(observer);

  this.observers.add(weakRefObserver);

 

  // Регистрирайте оригиналния обект на наблюдателя. Когато бъде събран,

  // финализаторът ще бъде извикан с `weakRefObserver` като аргумент.

  this.cleanupRegistry.register(observer, weakRefObserver);

 

  console.log('Наблюдател се е абонирал.');

}

Тази настройка създава умен цикъл: субектът държи слаба препратка към наблюдателя. Регистърът държи силна препратка към наблюдателя (вътрешно), докато не бъде събран от сборчика за отпадъци. Веднъж събран, callback функцията на регистъра се задейства с екземпляра на слабата препратка, който след това можем да използваме за почистване на нашия `observers` set.

Стъпка 3: Методът `unsubscribe`

Дори и с автоматичното почистване, все пак трябва да предоставим ръчен метод `unsubscribe` за случаи, когато е необходимо детерминистично премахване. Този метод ще трябва да намери правилния `WeakRef` в нашия set, като дереферира всеки един и го сравни с наблюдателя, който искаме да премахнем.

// Вътре в класа 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);

    // ВАЖНО: Трябва също така да дерегистрираме от финализатора

    // за да предотвратим ненужното изпълнение на callback по-късно.

    this.cleanupRegistry.unregister(observer);

    console.log('Наблюдател се е отписал ръчно.');

  }

}

Стъпка 4: Методът `notify`

Методът `notify` итерира върху нашия set от `WeakRef` обекти. За всеки един, той се опитва да го `deref()`-ира, за да получи действителния обект на наблюдателя. Ако `deref()` успее, това означава, че наблюдателят е все още жив и можем да извикаме неговия метод `update`. Ако върне `undefined`, наблюдателят е бил събран и можем просто да го игнорираме. `FinalizationRegistry` в крайна сметка ще премахне неговия `WeakRef` от set-а.

// Вътре в класа WeakRefSubject...

notify(data) {

  console.log('Уведомяване на наблюдатели...');

  for (const weakRefObserver of this.observers) {

    const observer = weakRefObserver.deref();

    if (observer) {

      // Наблюдателят е все още жив

      observer.update(data);

    } else {

      // Наблюдателят е събран от сборчика за отпадъци.

      // FinalizationRegistry ще се погрижи за премахването на този weakRef от set-а.

      console.log('Намерена е мъртва препратка към наблюдател по време на известяване.');

  }

  }

}

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

Нека преразгледаме нашия сценарий с UI компонент, но този път използвайки нашия нов `WeakRefSubject`. Ще използваме същия клас `Observer` като преди, за простота.

// Същият прост клас Observer

class Observer {

  constructor(name) {

    this.name = name;

  }

  update(data) {

    console.log(`${this.name} получи данни: ${data}`);

  }

}

Сега, нека създадем глобална услуга за данни и симулираме временен UI елемент.

const globalDataService = new WeakRefSubject();

 

function createAndDestroyWidget() {

  console.log('--- Създаване и абониране на нов елемент ---');

  let chartWidget = new Observer('RealTimeChartWidget');

  globalDataService.subscribe(chartWidget);

 

  // Елементът вече е активен и ще получава известия

  globalDataService.notify({ price: 100 });

 

  console.log('--- Унищожаване на елемент (освобождаване на нашата препратка) ---');

  // Приключихме с елемента. Задаваме нашата препратка на null.

  // НЕ е необходимо да извикваме unsubscribe().

  chartWidget = null;

}

 

createAndDestroyWidget();

 

console.log('--- След унищожаване на елемента, преди събиране на отпадъци ---');

globalDataService.notify({ price: 105 });

След изпълнението на `createAndDestroyWidget()`, обектът `chartWidget` вече е рефериран само от `WeakRef` вътре в нашия `globalDataService`. Тъй като това е слаба препратка, обектът вече е годен за събиране от сборчика за отпадъци.

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

1. Обектът `chartWidget` ще бъде премахнат от паметта.
2. Callback функцията на нашия `FinalizationRegistry` ще бъде задействана, която след това ще премахне вече мъртвия `WeakRef` от `globalDataService.observers` set-а.

Ако извикаме `notify` отново след като сборчикът за отпадъци се е изпълнил, извикването на `deref()` ще върне `undefined`, мъртвият наблюдател ще бъде пропуснат и приложението ще продължи да работи ефективно без течове на памет. Успешно сме отделили жизнения цикъл на наблюдателя от субекта.

Кога да използвате (и кога да избягвате) модела `WeakRefObserver`

Този модел е мощен, но не е сребърен куршум. Той въвежда сложност и разчита на недетерминистично поведение. От решаващо значение е да се знае кога е правилният инструмент за работата.

Идеални случаи на употреба

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

Кога да се придържаме към класическия Observer

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

По-широки последици за софтуерната архитектура

Въвеждането на слаби препратки във език от високо ниво като JavaScript сигнализира за зрялост на платформата. То позволява на разработчиците да изграждат по-сложни и устойчиви системи, особено за дълготрайни приложения. Този модел насърчава промяна в архитектурното мислене:

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

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

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

Пътувахме от разбирането на основния проблем с остатъчните препратки до изграждането на пълен, осъзнаващ паметта `WeakRefSubject` от нулата. Видяхме как `WeakRef` позволява обектите да бъдат събирани от сборчика за отпадъци, дори когато са "наблюдавани", и как `FinalizationRegistry` предоставя автоматизирания механизъм за почистване, за да поддържа нашия списък с наблюдатели безупречен.

Въпреки това, с голямата сила идва и голяма отговорност. Това са усъвършенствани функции, чиято недетерминистична природа изисква внимателно обмисляне. Те не са заместител на добрия дизайн на приложението и усърдното управление на жизнения цикъл. Но когато се прилага към правилните проблеми – като управление на комуникацията между дълготрайни услуги и ефимерни компоненти – моделът WeakRef Observer е изключително мощна техника. Като го овладеете, можете да пишете по-стабилни, ефективни и мащабируеми JavaScript приложения, готови да отговорят на изискванията на модерния, динамичен уеб.