Mẫu Observer sử dụng JavaScript WeakRef: Xây dựng Hệ thống Sự kiện Tối ưu Bộ nhớ

Trong thế giới phát triển web hiện đại, Các Ứng dụng Trang Đơn (SPAs) đã trở thành tiêu chuẩn để tạo ra trải nghiệm người dùng động và phản hồi nhanh. Các ứng dụng này thường chạy trong thời gian dài, quản lý trạng thái phức tạp và xử lý vô số tương tác người dùng. Tuy nhiên, tuổi thọ này đi kèm với một chi phí ẩn: nguy cơ rò rỉ bộ nhớ tăng cao. Rò rỉ bộ nhớ, nơi một ứng dụng giữ lại bộ nhớ mà nó không còn cần, có thể làm giảm hiệu suất theo thời gian, dẫn đến chậm chạp, sự cố trình duyệt và trải nghiệm người dùng kém. Một trong những nguồn phổ biến nhất của những rò rỉ này nằm ở một mẫu thiết kế cơ bản: mẫu Observer.

Mẫu Observer là nền tảng của kiến trúc hướng sự kiện, cho phép các đối tượng (observers) đăng ký và nhận cập nhật từ một đối tượng trung tâm (subject). Nó thanh lịch, đơn giản và cực kỳ hữu ích. Nhưng việc triển khai cổ điển của nó có một lỗ hổng nghiêm trọng: subject duy trì các tham chiếu mạnh đến các observers của nó. Nếu một observer không còn được phần còn lại của ứng dụng cần đến, nhưng nhà phát triển quên hủy đăng ký rõ ràng nó khỏi subject, nó sẽ không bao giờ được thu gom rác. Nó vẫn bị mắc kẹt trong bộ nhớ, một "bóng ma" ám ảnh hiệu suất ứng dụng của bạn.

Đây là lúc JavaScript hiện đại, với các tính năng ECMAScript 2021 (ES12) của nó, cung cấp một giải pháp mạnh mẽ. Bằng cách tận dụng WeakRef và FinalizationRegistry, chúng ta có thể xây dựng một mẫu Observer nhận thức bộ nhớ, tự động dọn dẹp sau khi sử dụng, ngăn chặn những rò rỉ phổ biến này. Bài viết này sẽ đi sâu vào kỹ thuật tiên tiến này. Chúng ta sẽ khám phá vấn đề, hiểu các công cụ, xây dựng một triển khai mạnh mẽ từ đầu và thảo luận khi nào và ở đâu mẫu mạnh mẽ này nên được áp dụng trong các ứng dụng toàn cầu của bạn.

Hiểu vấn đề cốt lõi: Mẫu Observer cổ điển và dấu chân bộ nhớ của nó

Trước khi chúng ta có thể đánh giá cao giải pháp, chúng ta phải nắm bắt đầy đủ vấn đề. Mẫu Observer, còn được gọi là mẫu Publisher-Subscriber, được thiết kế để tách rời các thành phần. Một Subject (hoặc Publisher) duy trì một danh sách các phần phụ thuộc của nó, được gọi là Observers (hoặc Subscribers). Khi trạng thái của Subject thay đổi, nó sẽ tự động thông báo cho tất cả các Observers của nó, thường bằng cách gọi một phương thức cụ thể trên chúng, chẳng hạn như update().

Hãy xem xét một triển khai cổ điển, đơn giản trong JavaScript.

Một Triển khai Subject Đơn giản

Đây là một lớp Subject cơ bản. Nó có các phương thức để đăng ký, hủy đăng ký và thông báo cho observers.

class ClassicSubject {

  constructor() {

    this.observers = [];

  }

 

  subscribe(observer) {

    this.observers.push(observer);

    console.log(`${observer.name} đã đăng ký.`);

  }

 

  unsubscribe(observer) {

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

    console.log(`${observer.name} đã hủy đăng ký.`);

  }

 

  notify(data) {

    console.log('Đang thông báo cho observers...');

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

  }

}

Và đây là một lớp Observer đơn giản có thể đăng ký với Subject.

class Observer {

  constructor(name) {

    this.name = name;

  }

 

  update(data) {

    console.log(`${this.name} đã nhận dữ liệu: ${data}`);

  }

}

Nguy hiểm tiềm ẩn: Các tham chiếu còn sót lại

Việc triển khai này hoạt động hoàn hảo miễn là chúng ta quản lý vòng đời của các observers một cách cẩn thận. Vấn đề phát sinh khi chúng ta không làm như vậy. Hãy xem xét một kịch bản phổ biến trong một ứng dụng lớn: một kho dữ liệu toàn cầu tồn tại lâu dài (Subject) và một thành phần UI tạm thời (Observer) hiển thị một số dữ liệu đó.

Hãy mô phỏng kịch bản này:

const dataStore = new ClassicSubject();

 

function manageUIComponent() {

  let chartComponent = new Observer('ChartComponent');

  dataStore.subscribe(chartComponent);

 

  // Thành phần thực hiện công việc của nó...

 

  // Giờ đây, người dùng điều hướng đi chỗ khác và thành phần không còn cần thiết nữa.

  // Một nhà phát triển có thể quên thêm mã dọn dẹp:

  // dataStore.unsubscribe(chartComponent);

 

  chartComponent = null; // Chúng ta giải phóng tham chiếu của mình đến thành phần.

}

 

manageUIComponent();

 

// Sau đó trong vòng đời ứng dụng...

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

Trong hàm `manageUIComponent`, chúng ta tạo một `chartComponent` và đăng ký nó vào `dataStore` của chúng ta. Sau đó, chúng ta đặt `chartComponent` thành `null`, báo hiệu rằng chúng ta đã hoàn tất với nó. Chúng ta mong đợi trình thu gom rác (GC) của JavaScript sẽ thấy rằng không còn tham chiếu nào đến đối tượng này và thu hồi bộ nhớ của nó.

Nhưng vẫn còn một tham chiếu! Mảng `dataStore.observers` vẫn giữ một tham chiếu mạnh trực tiếp đến đối tượng `chartComponent`. Vì tham chiếu duy nhất còn sót lại này, trình thu gom rác không thể thu hồi bộ nhớ. Đối tượng `chartComponent` và bất kỳ tài nguyên nào nó giữ, sẽ vẫn còn trong bộ nhớ trong toàn bộ vòng đời của `dataStore`. Nếu điều này xảy ra lặp đi lặp lại — ví dụ, mỗi khi người dùng mở và đóng một cửa sổ modal — việc sử dụng bộ nhớ của ứng dụng sẽ tăng lên vô thời hạn. Đây là một rò rỉ bộ nhớ cổ điển.

Một Hy vọng mới: Giới thiệu WeakRef và FinalizationRegistry

ECMAScript 2021 đã giới thiệu hai tính năng mới được thiết kế đặc biệt để xử lý các loại thách thức quản lý bộ nhớ này: `WeakRef` và `FinalizationRegistry`. Chúng là các công cụ tiên tiến và nên được sử dụng cẩn thận, nhưng đối với vấn đề mẫu Observer của chúng ta, chúng là giải pháp hoàn hảo.

WeakRef là gì?

Một đối tượng `WeakRef` giữ một tham chiếu yếu đến một đối tượng khác, được gọi là mục tiêu của nó. Sự khác biệt chính giữa tham chiếu yếu và tham chiếu thông thường (mạnh) là: tham chiếu yếu không ngăn đối tượng mục tiêu của nó bị thu gom rác.

Nếu các tham chiếu duy nhất đến một đối tượng là các tham chiếu yếu, công cụ JavaScript có thể tự do hủy đối tượng và thu hồi bộ nhớ của nó. Đây chính xác là điều chúng ta cần để giải quyết vấn đề Observer của mình.

Để sử dụng `WeakRef`, bạn tạo một phiên bản của nó, truyền đối tượng mục tiêu vào hàm tạo. Để truy cập đối tượng mục tiêu sau này, bạn sử dụng phương thức `deref()`.

let targetObject = { id: 42 };

const weakRefToObject = new WeakRef(targetObject);

 

// Để truy cập đối tượng:

const retrievedObject = weakRefToObject.deref();

 

if (retrievedObject) {

  console.log(`Đối tượng vẫn còn tồn tại: ${retrievedObject.id}`); // Kết quả: Đối tượng vẫn còn tồn tại: 42

} else {

  console.log('Đối tượng đã bị thu gom rác.');

}

Phần quan trọng là `deref()` có thể trả về `undefined`. Điều này xảy ra nếu `targetObject` đã bị thu gom rác vì không còn tham chiếu mạnh nào đến nó nữa. Hành vi này là nền tảng của mẫu Observer nhận thức bộ nhớ của chúng ta.

FinalizationRegistry là gì?

Trong khi `WeakRef` cho phép một đối tượng được thu gom, nó không cung cấp cho chúng ta một cách rõ ràng để biết khi nào nó đã được thu gom. Chúng ta có thể định kỳ kiểm tra `deref()` và loại bỏ các kết quả `undefined` khỏi danh sách observers của chúng ta, nhưng điều đó không hiệu quả. Đây là lúc `FinalizationRegistry` phát huy tác dụng.

Một `FinalizationRegistry` cho phép bạn đăng ký một hàm callback sẽ được gọi sau khi một đối tượng đã đăng ký đã bị thu gom rác. Đó là một cơ chế để dọn dẹp sau khi đối tượng bị hủy.

Đây là cách nó hoạt động:

1. Bạn tạo một registry với một callback dọn dẹp.
2. Bạn `register()` một đối tượng với registry. Bạn cũng có thể cung cấp một `heldValue`, đó là một phần dữ liệu sẽ được truyền cho callback của bạn khi đối tượng được thu gom. `heldValue` này không được là một tham chiếu trực tiếp đến chính đối tượng, vì điều đó sẽ làm mất đi mục đích!

// 1. Tạo registry với callback dọn dẹp

const registry = new FinalizationRegistry(heldValue => {

  console.log(`Một đối tượng đã bị thu gom rác. Mã thông báo dọn dẹp: ${heldValue}`);

});

 

(function() {

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

  let cleanupToken = 'temp-data-123';

 

  // 2. Đăng ký đối tượng và cung cấp mã thông báo để dọn dẹp

  registry.register(objectToTrack, cleanupToken);

 

  // objectToTrack ra khỏi phạm vi ở đây

})();

 

// Tại một thời điểm nào đó trong tương lai, sau khi GC chạy, console sẽ ghi lại:

// "Một đối tượng đã bị thu gom rác. Mã thông báo dọn dẹp: temp-data-123"

Những Lưu ý Quan trọng và Thực hành Tốt nhất

Trước khi chúng ta đi sâu vào việc triển khai, điều quan trọng là phải hiểu bản chất của những công cụ này. Hành vi của trình thu gom rác phụ thuộc rất nhiều vào việc triển khai và không xác định. Điều này có nghĩa là:

• Bạn không thể dự đoán khi nào một đối tượng sẽ được thu gom. Có thể là vài giây, vài phút hoặc thậm chí lâu hơn sau khi nó trở nên không thể truy cập được.
• Bạn không thể dựa vào các callback của `FinalizationRegistry` để chạy một cách kịp thời hoặc có thể dự đoán được. Chúng dành cho việc dọn dẹp, không phải cho logic ứng dụng quan trọng.
• Việc lạm dụng `WeakRef` và `FinalizationRegistry` có thể làm cho mã khó hiểu hơn. Luôn ưu tiên các giải pháp đơn giản hơn (như các lệnh gọi `unsubscribe` rõ ràng) nếu vòng đời đối tượng rõ ràng và có thể quản lý được.

Các tính năng này phù hợp nhất cho các tình huống mà vòng đời của một đối tượng (observer) thực sự độc lập và không được biết đến bởi một đối tượng khác (subject).

Xây dựng mẫu `WeakRefObserver`: Triển khai từng bước

Bây giờ, hãy kết hợp `WeakRef` và `FinalizationRegistry` để xây dựng một lớp `WeakRefSubject` an toàn bộ nhớ.

Bước 1: Cấu trúc lớp `WeakRefSubject`

Lớp mới của chúng ta sẽ lưu trữ các `WeakRef` đến observers thay vì các tham chiếu trực tiếp. Nó cũng sẽ có một `FinalizationRegistry` để xử lý việc dọn dẹp tự động danh sách observers.

class WeakRefSubject {

  constructor() {

    this.observers = new Set(); // Sử dụng Set để dễ dàng loại bỏ hơn

 

    // Callback finalizer. Nó nhận giá trị được giữ mà chúng ta cung cấp trong quá trình đăng ký.

    // Trong trường hợp của chúng ta, giá trị được giữ sẽ là chính thể hiện WeakRef.

    this.cleanupRegistry = new FinalizationRegistry(weakRefObserver => {

      console.log('Finalizer: Một observer đã bị thu gom rác. Đang dọn dẹp...');

      this.observers.delete(weakRefObserver);

    });

  }

}

Chúng ta sử dụng một `Set` thay vì một `Array` cho danh sách observers của mình. Điều này là do việc xóa một mục khỏi `Set` hiệu quả hơn nhiều (độ phức tạp thời gian trung bình O(1)) so với việc lọc một `Array` (O(n)), điều này sẽ hữu ích trong logic dọn dẹp của chúng ta.

Bước 2: Phương thức `subscribe`

Phương thức `subscribe` là nơi điều kỳ diệu bắt đầu. Khi một observer đăng ký, chúng ta sẽ:

1. Tạo một `WeakRef` trỏ đến observer.
2. Thêm `WeakRef` này vào tập `observers` của chúng ta.
3. Đăng ký đối tượng observer gốc với `FinalizationRegistry` của chúng ta, sử dụng `WeakRef` mới tạo làm `heldValue`.

// Bên trong lớp WeakRefSubject...

subscribe(observer) {

  // Kiểm tra xem một observer với tham chiếu này đã tồn tại chưa

  for (const ref of this.observers) {

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

      console.warn('Observer đã được đăng ký.');

      return;

    }

  }

 

  const weakRefObserver = new WeakRef(observer);

  this.observers.add(weakRefObserver);

 

  // Đăng ký đối tượng observer gốc. Khi nó được thu gom,

  // finalizer sẽ được gọi với `weakRefObserver` làm đối số.

  this.cleanupRegistry.register(observer, weakRefObserver);

 

  console.log('Một observer đã đăng ký.');

}

Thiết lập này tạo ra một vòng lặp thông minh: subject giữ một tham chiếu yếu đến observer. Registry giữ một tham chiếu mạnh đến observer (nội bộ) cho đến khi nó được thu gom rác. Một khi đã được thu gom, callback của registry được kích hoạt với thể hiện tham chiếu yếu, mà chúng ta có thể sử dụng để dọn dẹp tập `observers` của mình.

Bước 3: Phương thức `unsubscribe`

Ngay cả khi có tính năng dọn dẹp tự động, chúng ta vẫn nên cung cấp một phương thức `unsubscribe` thủ công cho các trường hợp cần loại bỏ một cách xác định. Phương thức này sẽ cần tìm `WeakRef` chính xác trong tập của chúng ta bằng cách dereference từng tham chiếu và so sánh nó với observer mà chúng ta muốn loại bỏ.

// Bên trong lớp 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);

    // QUAN TRỌNG: Chúng ta cũng phải hủy đăng ký khỏi finalizer

    // để ngăn callback chạy một cách không cần thiết sau này.

    this.cleanupRegistry.unregister(observer);

    console.log('Một observer đã hủy đăng ký thủ công.');

  }

}

Bước 4: Phương thức `notify`

Phương thức `notify` lặp qua tập hợp các `WeakRef` của chúng ta. Đối với mỗi tham chiếu, nó cố gắng `deref()` để lấy đối tượng observer thực tế. Nếu `deref()` thành công, điều đó có nghĩa là observer vẫn còn sống và chúng ta có thể gọi phương thức `update` của nó. Nếu nó trả về `undefined`, observer đã được thu gom và chúng ta chỉ cần bỏ qua nó. `FinalizationRegistry` cuối cùng sẽ loại bỏ `WeakRef` của nó khỏi tập hợp.

// Bên trong lớp WeakRefSubject...

notify(data) {

  console.log('Đang thông báo cho observers...');

  for (const weakRefObserver of this.observers) {

    const observer = weakRefObserver.deref();

    if (observer) {

      // Observer vẫn còn sống

      observer.update(data);

    } else {

      // Observer đã bị thu gom rác.

      // FinalizationRegistry sẽ xử lý việc loại bỏ weakRef này khỏi tập hợp.

      console.log('Tìm thấy tham chiếu observer đã chết trong quá trình thông báo.');

    }

  }

}

Tổng hợp lại: Một ví dụ thực tế

Hãy xem xét lại kịch bản thành phần UI của chúng ta, nhưng lần này sử dụng `WeakRefSubject` mới của chúng ta. Chúng ta sẽ sử dụng cùng lớp `Observer` như trước để đơn giản.

// Lớp Observer đơn giản tương tự

class Observer {

  constructor(name) {

    this.name = name;

  }

  update(data) {

    console.log(`${this.name} đã nhận dữ liệu: ${data}`);

  }

}

Bây giờ, hãy tạo một dịch vụ dữ liệu toàn cầu và mô phỏng một widget UI tạm thời.

const globalDataService = new WeakRefSubject();

function createAndDestroyWidget() {

  console.log('--- Đang tạo và đăng ký widget mới ---');

  let chartWidget = new Observer('RealTimeChartWidget');

  globalDataService.subscribe(chartWidget);

 

  // Widget hiện đang hoạt động và sẽ nhận thông báo

  globalDataService.notify({ price: 100 });

 

  console.log('--- Đang hủy widget (giải phóng tham chiếu của chúng ta) ---');

  // Chúng ta đã xong với widget. Chúng ta đặt tham chiếu của mình thành null.

  // Chúng ta KHÔNG cần gọi unsubscribe().

  chartWidget = null;

}

createAndDestroyWidget();

console.log('--- Sau khi hủy widget, trước khi thu gom rác ---');

globalDataService.notify({ price: 105 });

Sau khi chạy `createAndDestroyWidget()`, đối tượng `chartWidget` giờ đây chỉ được tham chiếu bởi `WeakRef` bên trong `globalDataService` của chúng ta. Bởi vì đây là một tham chiếu yếu, đối tượng hiện đủ điều kiện để thu gom rác.

Khi trình thu gom rác cuối cùng chạy (điều mà chúng ta không thể dự đoán), hai điều sẽ xảy ra:

1. Đối tượng `chartWidget` sẽ bị xóa khỏi bộ nhớ.
2. Callback của `FinalizationRegistry` của chúng ta sẽ được kích hoạt, sau đó sẽ loại bỏ `WeakRef` đã chết khỏi tập hợp `globalDataService.observers`.

Nếu chúng ta gọi `notify` một lần nữa sau khi trình thu gom rác đã chạy, lệnh gọi `deref()` sẽ trả về `undefined`, observer đã chết sẽ bị bỏ qua và ứng dụng tiếp tục chạy hiệu quả mà không có bất kỳ rò rỉ bộ nhớ nào. Chúng ta đã thành công tách rời vòng đời của observer khỏi subject.

Khi nào nên sử dụng (và khi nào nên tránh) mẫu `WeakRefObserver`

Mẫu này rất mạnh mẽ, nhưng nó không phải là viên đạn bạc. Nó giới thiệu sự phức tạp và dựa vào hành vi không xác định. Điều quan trọng là phải biết khi nào nó là công cụ phù hợp cho công việc.

Các Trường hợp Sử dụng Lý tưởng

• Subjects tồn tại lâu dài và Observers tồn tại ngắn hạn: Đây là trường hợp sử dụng điển hình. Một dịch vụ toàn cầu, kho dữ liệu hoặc bộ nhớ cache (subject) tồn tại trong toàn bộ vòng đời ứng dụng, trong khi nhiều thành phần UI, workers tạm thời hoặc plugin (observers) được tạo và hủy thường xuyên.
• Cơ chế Bộ nhớ đệm (Caching Mechanisms): Hãy tưởng tượng một bộ nhớ đệm ánh xạ một đối tượng phức tạp tới một kết quả đã tính toán. Bạn có thể sử dụng `WeakRef` cho đối tượng khóa. Nếu đối tượng gốc được thu gom rác khỏi phần còn lại của ứng dụng, `FinalizationRegistry` có thể tự động dọn dẹp mục tương ứng trong bộ nhớ đệm của bạn, ngăn chặn sự phình to của bộ nhớ.
• Kiến trúc Plugin và Mở rộng: Nếu bạn đang xây dựng một hệ thống cốt lõi cho phép các mô-đun của bên thứ ba đăng ký các sự kiện, việc sử dụng `WeakRefObserver` sẽ thêm một lớp khả năng phục hồi. Nó ngăn chặn một plugin được viết kém, quên hủy đăng ký, gây ra rò rỉ bộ nhớ trong ứng dụng cốt lõi của bạn.
• Ánh xạ Dữ liệu tới các Phần tử DOM: Trong các kịch bản không có một framework khai báo, bạn có thể muốn liên kết một số dữ liệu với một phần tử DOM. Nếu bạn lưu trữ điều này trong một map với phần tử DOM làm khóa, bạn có thể tạo ra rò rỉ bộ nhớ nếu phần tử bị xóa khỏi DOM nhưng vẫn còn trong map của bạn. `WeakMap` là một lựa chọn tốt hơn ở đây, nhưng nguyên tắc là như nhau: vòng đời của dữ liệu nên được gắn với vòng đời của phần tử, chứ không phải ngược lại.

Khi nào nên giữ lại mẫu Observer cổ điển

• Vòng đời Kết nối chặt chẽ: Nếu subject và các observers của nó luôn được tạo và hủy cùng nhau hoặc trong cùng một phạm vi, thì chi phí và sự phức tạp của `WeakRef` là không cần thiết. Một lệnh gọi `unsubscribe()` đơn giản, rõ ràng sẽ dễ đọc và dễ đoán hơn.
• Đường dẫn nóng quan trọng về hiệu suất: Phương thức `deref()` có một chi phí hiệu suất nhỏ nhưng không bằng không. Nếu bạn đang thông báo cho hàng nghìn observers hàng trăm lần mỗi giây (ví dụ: trong một vòng lặp trò chơi hoặc hiển thị dữ liệu tần số cao), việc triển khai cổ điển với các tham chiếu trực tiếp sẽ nhanh hơn.
• Ứng dụng và Script đơn giản: Đối với các ứng dụng hoặc script nhỏ hơn mà thời gian tồn tại của ứng dụng ngắn và quản lý bộ nhớ không phải là mối quan tâm đáng kể, mẫu cổ điển đơn giản hơn để triển khai và hiểu. Đừng thêm sự phức tạp vào nơi không cần thiết.
• Khi cần Dọn dẹp xác định: Nếu bạn cần thực hiện một hành động tại thời điểm chính xác một observer bị tách rời (ví dụ: cập nhật bộ đếm, giải phóng một tài nguyên phần cứng cụ thể), bạn phải sử dụng phương thức `unsubscribe()` thủ công. Bản chất không xác định của `FinalizationRegistry` làm cho nó không phù hợp cho logic phải thực thi một cách có thể dự đoán được.

Ý nghĩa rộng lớn hơn đối với Kiến trúc Phần mềm

Việc giới thiệu các tham chiếu yếu vào một ngôn ngữ cấp cao như JavaScript báo hiệu sự trưởng thành của nền tảng. Nó cho phép các nhà phát triển xây dựng các hệ thống tinh vi và kiên cường hơn, đặc biệt đối với các ứng dụng chạy dài. Mẫu này khuyến khích một sự thay đổi trong tư duy kiến trúc:

• Sự tách rời thực sự: Nó cho phép một mức độ tách rời vượt xa chỉ giao diện. Giờ đây chúng ta có thể tách rời chính vòng đời của các thành phần. Subject không còn cần biết bất cứ điều gì về thời điểm các observers của nó được tạo hoặc hủy.
• Khả năng phục hồi theo thiết kế: Nó giúp xây dựng các hệ thống có khả năng phục hồi tốt hơn đối với lỗi của lập trình viên. Một lệnh gọi `unsubscribe()` bị quên là một lỗi phổ biến có thể khó theo dõi. Mẫu này giảm thiểu toàn bộ loại lỗi đó.
• Kích hoạt các tác giả Framework và Thư viện: Đối với những người xây dựng framework, thư viện hoặc nền tảng cho các nhà phát triển khác, những công cụ này là vô giá. Chúng cho phép tạo ra các API mạnh mẽ ít bị lạm dụng bởi người dùng thư viện, dẫn đến các ứng dụng ổn định hơn nói chung.

Kết luận: Một Công cụ Mạnh mẽ cho Nhà phát triển JavaScript hiện đại

Mẫu Observer cổ điển là một khối xây dựng cơ bản của thiết kế phần mềm, nhưng sự phụ thuộc của nó vào các tham chiếu mạnh từ lâu đã là nguồn gây ra các rò rỉ bộ nhớ tinh vi và khó chịu trong các ứng dụng JavaScript. Với sự xuất hiện của `WeakRef` và `FinalizationRegistry` trong ES2021, giờ đây chúng ta có các công cụ để khắc phục hạn chế này.

Chúng ta đã đi từ việc hiểu vấn đề cơ bản về các tham chiếu còn sót lại đến việc xây dựng một `WeakRefSubject` hoàn chỉnh, nhận thức bộ nhớ từ đầu. Chúng ta đã thấy cách `WeakRef` cho phép các đối tượng được thu gom rác ngay cả khi đang được 'quan sát', và cách `FinalizationRegistry` cung cấp cơ chế dọn dẹp tự động để giữ danh sách observers của chúng ta luôn sạch sẽ.

Tuy nhiên, với sức mạnh lớn đi kèm với trách nhiệm lớn. Đây là những tính năng nâng cao mà bản chất không xác định của chúng đòi hỏi sự cân nhắc kỹ lưỡng. Chúng không phải là sự thay thế cho thiết kế ứng dụng tốt và quản lý vòng đời cẩn thận. Nhưng khi được áp dụng đúng vấn đề — chẳng hạn như quản lý giao tiếp giữa các dịch vụ tồn tại lâu dài và các thành phần nhất thời — mẫu WeakRef Observer là một kỹ thuật đặc biệt mạnh mẽ. Bằng cách làm chủ nó, bạn có thể viết các ứng dụng JavaScript mạnh mẽ hơn, hiệu quả hơn và có khả năng mở rộng hơn, sẵn sàng đáp ứng các yêu cầu của web hiện đại, năng động.