深入探讨 JavaScript 的 WeakRef 和 FinalizationRegistry，以创建内存高效的观察者模式。学习如何在大规模应用中防止内存泄漏。
JavaScript WeakRef 观察者模式：构建内存感知事件系统
在现代Web开发领域，单页应用（SPA）已成为创建动态和响应式用户体验的标准。这些应用通常长时间运行，管理着复杂的状态并处理无数的用户交互。然而，这种持久性带来了一个隐藏的代价：内存泄漏的风险增加了。内存泄漏，即应用持有不再需要的内存，会随着时间的推移降低性能，导致应用反应迟钝、浏览器崩溃以及糟糕的用户体验。这些泄漏最常见的来源之一，就潜藏在一个基础的设计模式中：观察者模式。
观察者模式是事件驱动架构的基石，它使对象（观察者）能够订阅并接收来自一个中心对象（主题）的更新。它优雅、简单且极其有用。但其经典实现存在一个致命缺陷：主题维护着对其观察者的强引用。如果一个观察者不再被应用的其他部分需要，但开发者忘记从主题中明确地取消订阅，它将永远不会被垃圾回收。它会像一个幽灵一样被困在内存中，困扰着你的应用性能。
这正是现代 JavaScript 及其 ECMAScript 2021 (ES12) 特性提供强大解决方案的地方。通过利用 WeakRef 和 FinalizationRegistry，我们可以构建一个能够自动清理的、具有内存意识的观察者模式，从而防止这些常见的泄漏。本文将深入探讨这一先进技术。我们将剖析问题、理解工具、从零开始构建一个健壮的实现，并讨论在你的全球应用中何时何地应该应用这种强大的模式。
理解核心问题：经典观察者模式及其内存足迹
在我们领会解决方案之前，我们必须完全掌握问题所在。观察者模式，也称为发布者-订阅者模式，旨在解耦组件。一个主题（或发布者）维护一个其依赖项的列表，称为观察者（或订阅者）。当主题的状态改变时，它会自动通知其所有观察者，通常是通过调用它们身上的特定方法，例如update()。
让我们看一个简单的 JavaScript 经典实现。
一个简单的主题实现
这是一个基础的 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));
}
}
这里是一个可以订阅 Subject 的简单 Observer 类。
class Observer {
constructor(name) {
this.name = name;
}
update(data) {
console.log(`${this.name} 收到数据: ${data}`);
}
}
隐藏的危险：挥之不去的引用
只要我们勤于管理观察者的生命周期，这个实现就能完美工作。问题出在我们疏忽的时候。考虑一个大型应用中的常见场景：一个长期存在的全局数据存储（主题）和一个显示部分数据的临时 UI 组件（观察者）。
让我们模拟一下这个场景：
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`。它们是高级工具，应谨慎使用，但对于我们的观察者模式问题，它们是完美的解决方案。
什么是 WeakRef？
一个 `WeakRef` 对象持有一个对其目标对象的弱引用。弱引用和普通（强）引用的关键区别在于：弱引用不会阻止其目标对象被垃圾回收。
如果一个对象仅被弱引用所指向，JavaScript 引擎就可以自由地销毁该对象并回收其内存。这正是我们解决观察者问题所需要的。
要使用 `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` 因为不再有强引用指向它而被垃圾回收，就会发生这种情况。这种行为是我们内存感知观察者模式的基础。
什么是 FinalizationRegistry？
虽然 `WeakRef` 允许一个对象被回收，但它没有提供一个干净的方式来知晓对象是何时被回收的。我们可以定期检查 `deref()` 并从我们的观察者列表中移除 `undefined` 的结果，但这效率低下。这就是 `FinalizationRegistry` 发挥作用的地方。
一个 `FinalizationRegistry` 允许你注册一个回调函数，该函数将在一个已注册的对象被垃圾回收之后被调用。这是一种用于事后清理的机制。
它的工作原理如下：
- 你创建一个带有清理回调的注册表。
- 你使用 `register()` 方法将一个对象注册到该注册表。你还可以提供一个 `heldValue`，这是一份数据，当对象被回收时，它将被传递给你的回调函数。这个 `heldValue` 不能是对该对象本身的直接引用，因为那会使其无法被回收！
// 1. 创建带有清理回调的注册表
const registry = new FinalizationRegistry(heldValue => {
console.log(`一个对象已被垃圾回收。清理令牌: ${heldValue}`);
});
(function() {
let objectToTrack = { name: 'Temporary Data' };
let cleanupToken = 'temp-data-123';
// 2. 注册对象并提供一个用于清理的令牌
registry.register(objectToTrack, cleanupToken);
// objectToTrack 在这里超出作用域
})();
// 在未来的某个时刻，GC 运行之后，控制台将输出：
// "一个对象已被垃圾回收。清理令牌: temp-data-123"
重要警告和最佳实践
在我们深入实现之前，理解这些工具的本质至关重要。垃圾回收器的行为是高度依赖于具体实现且不确定的。这意味着：
- 你无法预测一个对象何时会被回收。可能是在它变得不可达之后的几秒、几分钟，甚至更长时间。
- 你不能依赖 `FinalizationRegistry` 的回调会及时或可预测地运行。它们是用于清理，而不是用于关键的应用程序逻辑。
- 过度使用 `WeakRef` 和 `FinalizationRegistry` 会使代码更难理解。如果对象的生命周期清晰可控，应始终优先选择更简单的解决方案（如显式调用 `unsubscribe`）。
这些特性最适用于一个对象（观察者）的生命周期真正独立于且不为另一个对象（主题）所知的场景。
构建 `WeakRefObserver` 模式：分步实现
现在，让我们结合 `WeakRef` 和 `FinalizationRegistry` 来构建一个内存安全的 `WeakRefSubject` 类。
第一步：`WeakRefSubject` 类的结构
我们的新类将存储指向观察者的 `WeakRef`，而不是直接引用。它还将有一个 `FinalizationRegistry` 来处理观察者列表的自动清理。
class WeakRefSubject {
constructor() {
this.observers = new Set(); // 使用 Set 以便更容易地移除
// 终结器回调。它接收我们在注册时提供的 held value。
// 在我们的例子中，held value 将是 WeakRef 实例本身。
this.cleanupRegistry = new FinalizationRegistry(weakRefObserver => {
console.log('终结器：一个观察者已被垃圾回收。正在清理...');
this.observers.delete(weakRefObserver);
});
}
}
我们使用 `Set` 而不是 `Array` 来存储我们的观察者列表。这是因为从 `Set` 中删除一个项比过滤一个 `Array` 效率高得多（平均时间复杂度为 O(1)，而数组过滤是 O(n)），这在我们的清理逻辑中将非常有用。
第二步：`subscribe` 方法
`subscribe` 方法是魔法开始的地方。当一个观察者订阅时，我们将：
- 创建一个指向该观察者的 `WeakRef`。
- 将这个 `WeakRef` 添加到我们的 `observers` 集合中。
- 将原始观察者对象注册到我们的 `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('一个观察者已订阅。');
}
这个设置创建了一个巧妙的循环：主题持有对观察者的弱引用。注册表（在内部）持有对观察者的强引用，直到它被垃圾回收。一旦被回收，注册表的回调就会被触发，并传入弱引用实例，然后我们就可以用它来清理我们的 `observers` 集合。
第三步：`unsubscribe` 方法
即使有自动清理，我们仍然应该提供一个手动的 `unsubscribe` 方法，以应对需要确定性移除的情况。这个方法需要通过解引用集合中的每个 `WeakRef` 并将其与我们想要移除的观察者进行比较，来找到正确的 `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('一个观察者已手动取消订阅。');
}
}
第四步：`notify` 方法
`notify` 方法遍历我们的 `WeakRef` 集合。对于每一个 `WeakRef`，它会尝试 `deref()` 以获取实际的观察者对象。如果 `deref()` 成功，意味着观察者仍然存在，我们可以调用它的 `update` 方法。如果它返回 `undefined`，说明观察者已被回收，我们可以简单地忽略它。`FinalizationRegistry` 最终会从集合中移除它的 `WeakRef`。
// 在 WeakRefSubject 类内部...
notify(data) {
console.log('正在通知观察者...');
for (const weakRefObserver of this.observers) {
const observer = weakRefObserver.deref();
if (observer) {
// 观察者仍然存活
observer.update(data);
} else {
// 观察者已被垃圾回收。
// FinalizationRegistry 将处理从集合中移除这个 weakRef 的工作。
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` 对象现在仅被我们 `globalDataService` 内部的 `WeakRef` 所引用。因为这是一个弱引用，所以该对象现在有资格被垃圾回收。
当垃圾回收器最终运行时（我们无法预测何时运行），会发生两件事：
- `chartWidget` 对象将从内存中移除。
- 我们的 `FinalizationRegistry` 的回调将被触发，然后它将从 `globalDataService.observers` 集合中移除那个现在已经死掉的 `WeakRef`。
如果在垃圾回收器运行后我们再次调用 `notify`，`deref()` 调用将返回 `undefined`，死掉的观察者将被跳过，应用程序将继续高效运行，没有任何内存泄漏。我们成功地解耦了观察者和主题的生命周期。
何时使用（以及何时避免）`WeakRefObserver` 模式
这个模式很强大，但它不是万能的。它引入了复杂性，并依赖于不确定性的行为。了解何时使用它是正确的工具至关重要。
理想的使用场景
- 长生命周期的主题和短生命周期的观察者： 这是典型的使用案例。一个存在于整个应用生命周期的全局服务、数据存储或缓存（主题），而大量的 UI 组件、临时工作者或插件（观察者）被频繁地创建和销毁。
- 缓存机制： 想象一个将复杂对象映射到某些计算结果的缓存。你可以对键对象使用 `WeakRef`。如果原始对象从应用的其他部分被垃圾回收，`FinalizationRegistry` 可以自动清理你缓存中的相应条目，防止内存膨胀。
- 插件和扩展架构： 如果你正在构建一个允许第三方模块订阅事件的核心系统，使用 `WeakRefObserver` 会增加一层弹性。它可以防止一个编写不佳、忘记取消订阅的插件在你的核心应用中造成内存泄漏。
- 将数据映射到 DOM 元素： 在没有声明式框架的场景中，你可能想将一些数据与一个 DOM 元素关联起来。如果你将此存储在一个以 DOM 元素为键的 Map 中，如果该元素从 DOM 中移除但仍在你的 Map 中，就可能造成内存泄漏。`WeakMap` 在这里是更好的选择，但原理是相同的：数据的生命周期应该与元素的生命周期绑定，而不是反过来。
何时坚持使用经典观察者模式
- 紧密耦合的生命周期： 如果主题和其观察者总是一起创建和销毁，或者在同一作用域内，那么 `WeakRef` 的开销和复杂性是不必要的。一个简单的、显式的 `unsubscribe()` 调用更具可读性和可预测性。
- 性能关键的热路径： `deref()` 方法有微小但非零的性能成本。如果你每秒需要通知成千上万的观察者数百次（例如，在游戏循环或高频数据可视化中），使用直接引用的经典实现会更快。
- 简单的应用和脚本： 对于较小的应用或脚本，其应用生命周期短，内存管理不是一个主要问题，经典模式更易于实现和理解。不要在不需要的地方增加复杂性。
- 需要确定性清理时： 如果你需要在观察者分离的那一刻精确地执行一个动作（例如，更新一个计数器，释放一个特定的硬件资源），你必须使用手动的 `unsubscribe()` 方法。`FinalizationRegistry` 的不确定性使其不适用于必须可预测执行的逻辑。
对软件架构的更广泛影响
在像 JavaScript 这样的高级语言中引入弱引用，标志着该平台的成熟。它允许开发者构建更复杂、更有弹性的系统，特别是对于长期运行的应用。这种模式鼓励了架构思维的转变：
- 真正的解耦： 它实现了一种超越接口层面的解耦。我们现在可以解耦组件的生命周期。主题不再需要知道其观察者何时被创建或销毁。
- 设计上的弹性： 它有助于构建对程序员错误更有弹性的系统。忘记调用 `unsubscribe()` 是一个常见的、难以追踪的错误。这种模式减轻了这一整类错误。
- 赋能框架和库的作者： 对于那些为其他开发者构建框架、库或平台的人来说，这些工具是无价的。它们允许创建更健壮的 API，这些 API 不易被库的消费者误用，从而带来更稳定的整体应用。
结论：现代 JavaScript 开发者的强大工具
经典的观察者模式是软件设计的基本构建块，但它对强引用的依赖长期以来一直是 JavaScript 应用中那些微妙且令人沮丧的内存泄漏的来源。随着 ES2021 中 `WeakRef` 和 `FinalizationRegistry` 的到来，我们现在有了克服这一限制的工具。
我们从理解挥之不去的引用这一根本问题，到从头开始构建一个完整的、具有内存意识的 `WeakRefSubject`。我们看到了 `WeakRef` 如何允许对象即使在被‘观察’时也能被垃圾回收，以及 `FinalizationRegistry` 如何提供自动清理机制来保持我们观察者列表的纯净。
然而，能力越大，责任越大。这些是高级特性，其不确定性的性质需要仔细考虑。它们不能替代良好的应用设计和勤勉的生命周期管理。但是，当应用于正确的问题时——例如管理长生命周期服务和临时组件之间的通信——WeakRef 观察者模式是一种异常强大的技术。通过掌握它，你可以编写更健壮、高效和可扩展的 JavaScript 应用，以满足现代动态 Web 的需求。