发布于 由admin

FinalizationRegistry 与 WeakRef：实现对象的生命周期监听与 Native 资源清理

FinalizationRegistry 与 WeakRef：实现对象的生命周期监听与 Native 资源清理

各位同仁，大家好。今天我们将深入探讨JavaScript中两个相对较新但功能强大的特性：WeakRef和FinalizationRegistry。这两个API共同为我们提供了一种前所未有的能力，即在JavaScript对象生命周期的末端——当它们即将被垃圾回收时——执行特定的清理操作或查询其存活状态。这对于管理与JavaScript对象关联的外部（Native）资源尤为重要，能够有效避免资源泄露。

1. 引言：JavaScript内存管理与资源清理的挑战

JavaScript作为一种高级编程语言，其最大的便利之一便是自动内存管理。开发者通常无需关心内存的分配与释放，这一切都由JavaScript引擎的垃圾回收器（Garbage Collector, GC）自动完成。

1.1 JavaScript的自动内存管理：垃圾回收机制

现代JavaScript引擎普遍采用“标记-清除”（Mark-and-Sweep）等算法来实现垃圾回收。其核心思想是：

  1. 可达性（Reachability）：从一组“根”（root）对象（例如全局对象window或global，以及当前函数调用栈上的局部变量）出发，通过引用链能够访问到的所有对象，都被认为是“可达的”（reachable），即仍在使用的对象。
  2. 标记：垃圾回收器会遍历所有根对象，并标记所有从根对象可达的对象。
  3. 清除：所有未被标记的对象，即从根对象不可达的对象，都被认为是“垃圾”，将被清除并回收其占据的内存。

这种机制在绝大多数情况下运行良好，极大地简化了开发者的工作。

1.2 但，存在例外：当JavaScript对象与外部（Native）资源关联时

尽管JavaScript的GC机制非常智能，但它只管理JavaScript堆上的内存。当一个JavaScript对象不仅仅是数据容器，还与一些“外部”或“Native”资源（例如文件句柄、网络连接、数据库连接、WebAssembly（WASM）内存、WebGL纹理、操作系统级资源锁等）关联时，问题就出现了。

考虑以下场景：

  • 一个JavaScript对象myFile代表一个打开的文件句柄。
  • 一个JavaScript对象dbConnection代表一个数据库连接。
  • 一个JavaScript对象wasmMemoryView代表WebAssembly模块分配的一块内存。

当这些JavaScript对象不再被引用，并最终被垃圾回收时，GC只会回收myFile、dbConnection、wasmMemoryView这些JavaScript对象本身所占用的内存。然而，它们所关联的底层文件句柄、数据库连接、WASM内存等外部资源，并不会被JavaScript的GC自动关闭或释放。如果开发者没有在JavaScript对象被GC之前显式地关闭这些外部资源，就会导致：

  • 资源泄露（Resource Leak）：文件句柄保持打开，网络端口保持占用，数据库连接未关闭，WASM内存未释放。这会逐渐耗尽系统资源，导致应用程序性能下降，甚至崩溃。
  • 性能问题：过多的未关闭连接可能导致数据库或服务器过载。

1.3 传统问题与现有工具的局限性

在WeakRef和FinalizationRegistry出现之前，处理这类问题通常依赖于以下策略：

  1. 显式地close()/dispose()方法：这是最常见且推荐的做法。开发者必须手动调用资源对象的close()或dispose()方法来释放外部资源。例如：

    class File {
    constructor(path) {
        this.id = Math.random().toString(36).substring(7); // 模拟文件句柄
        console.log(`文件 [${this.id}] 打开: ${path}`);
    }

    read() {
        console.log(`读取文件 [${this.id}]...`);
    }

    close() {
        console.log(`文件 [${this.id}] 关闭。`);
        this.id = null; // 标记为已关闭
    }
}

let myFile = new File("/path/to/data.txt");
myFile.read();
// ... 使用 myFile ...
myFile.close(); // 必须手动调用
myFile = null; // 允许GC回收JS对象

    这种方式要求开发者有高度的责任心，一旦忘记调用close()，就会发生泄露。在复杂的应用中，忘记调用或在错误处理路径中遗漏close()是常有的事。

  2. try...finally语句：对于同步操作，try...finally可以确保资源在代码块执行完毕后被释放，无论是否发生异常。

    class DatabaseConnection {
    constructor(dbName) {
        this.id = Math.random().toString(36).substring(7);
        console.log(`数据库连接 [${this.id}] 建立到: ${dbName}`);
    }

    query(sql) {
        console.log(`连接 [${this.id}] 执行查询: ${sql}`);
        return `Result for ${sql}`;
    }

    close() {
        console.log(`数据库连接 [${this.id}] 关闭。`);
    }
}

function performDatabaseOperation() {
    let connection;
    try {
        connection = new DatabaseConnection("my_app_db");
        const result = connection.query("SELECT * FROM users");
        console.log(result);
    } catch (error) {
        console.error("数据库操作出错:", error);
    } finally {
        if (connection) {
            connection.close(); // 确保关闭连接
        }
    }
}

performDatabaseOperation();

    这对于同步资源管理非常有效，但对于异步操作、跨模块的资源持有或更复杂的生命周期管理，try...finally显得力不从心。

  3. WeakMap和WeakSet：它们允许你存储弱引用的键（WeakMap）或弱引用的值（WeakSet）。当键（或值）所引用的对象被GC后，对应的条目会自动从WeakMap或WeakSet中移除。

    const objectMetadata = new WeakMap();

let obj = {};
objectMetadata.set(obj, { createdAt: Date.now() });

console.log(objectMetadata.get(obj)); // { createdAt: ... }

obj = null; // obj现在可以被GC
// 垃圾回收发生后，WeakMap中的对应条目也会被清除
// 但我们无法得知何时发生，也无法在此刻执行清理动作

    WeakMap和WeakSet的问题在于：它们只能让你在GC发生后，不再持有对相应键或值的引用，但它们不提供在GC发生时执行清理回调的能力。我们无法通过它们来“监听”一个对象何时被GC。

正是为了填补这一空白，ES2021（ECMAScript 2021）引入了WeakRef和FinalizationRegistry。

2. 弱引用登场：WeakRef

WeakRef，即“弱引用”，是JavaScript中一种特殊的引用类型。与我们平时使用的“强引用”（Strong Reference）不同，弱引用不会阻止其目标对象被垃圾回收器回收。

2.1 WeakRef是什么？

一个WeakRef对象包含对另一个对象的弱引用。如果一个对象只被弱引用所引用，那么它仍旧有资格被垃圾回收器回收。一旦目标对象被回收，弱引用就变得“悬空”，无法再获取到目标对象。

2.2 工作原理与创建

要创建一个WeakRef，只需将目标对象作为参数传递给WeakRef构造函数：

const targetObject = { name: "我是一个目标对象" };
const weakRef = new WeakRef(targetObject);

console.log("创建了一个弱引用:", weakRef);

此时，weakRef持有对targetObject的弱引用。targetObject仍然被targetObject这个变量名强引用着。

2.3 deref()方法：尝试获取目标对象

WeakRef实例提供了一个deref()方法，用于尝试获取其目标对象。

  • 如果目标对象尚未被垃圾回收，deref()会返回该目标对象的强引用。
  • 如果目标对象已经被垃圾回收，deref()会返回undefined。

让我们通过一个例子来观察：

let targetObject = { id: 101, data: "一些重要数据" };
const weakRef = new WeakRef(targetObject);

console.log("-----------------------------------------");
console.log("1. 初始状态：");
console.log("targetObject:", targetObject);
console.log("weakRef.deref():", weakRef.deref()); // 应该返回 targetObject

// 移除对 targetObject 的强引用
targetObject = null;

console.log("n-----------------------------------------");
console.log("2. 移除强引用后：");
console.log("targetObject (强引用变量):", targetObject); // null

// 此时，targetObject 已经没有强引用了，它有资格被垃圾回收。
// 但是，GC何时运行是不确定的。
// 为了模拟GC，我们可以在Node.js环境中使用 --expose-gc 标志，并通过 global.gc() 手动触发。
// 在浏览器中，无法手动触发GC。

// 假设我们现在模拟GC发生
// global.gc(); // 在Node.js中运行 `node --expose-gc your_script.js` 才能调用

console.log("n-----------------------------------------");
console.log("3. 尝试在GC后（或GC前）再次deref：");
// 再次尝试 deref。这里结果可能仍然是对象，因为GC尚未运行。
// 或者如果GC已经运行，则可能为 undefined。
const retrievedObject = weakRef.deref();
console.log("weakRef.deref():", retrievedObject);

if (retrievedObject) {
    console.log("目标对象仍然存活。");
} else {
    console.log("目标对象已被垃圾回收。");
}

// 为了更清晰地演示，我们可以在一个异步或延迟函数中检查
function checkWeakRefLater() {
    setTimeout(() => {
        console.log("n-----------------------------------------");
        console.log("4. 延迟检查 weakRef.deref()：");
        const finalRetrievedObject = weakRef.deref();
        console.log("weakRef.deref() (延迟检查):", finalRetrievedObject);

        if (finalRetrievedObject) {
            console.log("目标对象仍然存活 (GC尚未运行)。");
        } else {
            console.log("目标对象已被垃圾回收 (GC已运行)。");
        }
    }, 100); // 稍作延迟
}

checkWeakRefLater();

// 在Node.js中，如果运行 `node --expose-gc your_script.js`
// 并在 `targetObject = null;` 之后手动调用 `global.gc();`，
// 那么延迟检查时 `deref()` 几乎肯定会返回 `undefined`。

运行上述代码（在Node.js中带--expose-gc）：

node --expose-gc your_script.js

您会发现，在targetObject = null;之后，如果您立即调用global.gc()，那么后续的weakRef.deref()就会返回undefined。如果没有手动调用global.gc()，那么JavaScript引擎可能会在某个不确定的时间点执行GC，所以结果可能不确定。

2.4 WeakRef的适用场景

WeakRef主要用于实现那些希望在内存压力下能够自动清除的缓存或对象池。

  • 缓存机制：当你有一个大型缓存，其中的数据项可能占用大量内存，并且你希望在内存不足时，那些不再被应用程序其他部分强引用的缓存项能够自动被GC清除，从而释放内存。

    const cache = new Map(); // 这是一个强引用缓存

function getExpensiveData(key) {
    if (cache.has(key)) {
        console.log(`从强缓存中获取 ${key}`);
        return cache.get(key);
    }
    console.log(`计算并缓存昂贵数据 ${key}...`);
    const data = { /* 模拟昂贵计算结果 */ value: Math.random() };
    cache.set(key, data);
    return data;
}

let data1 = getExpensiveData("itemA");
let data2 = getExpensiveData("itemB");

// 假设现在希望实现一个弱缓存，当数据不再被使用时自动清除
const weakCache = new Map(); // 存储 WeakRef 的Map

function getWeaklyCachedData(key) {
    if (weakCache.has(key)) {
        const weakRef = weakCache.get(key);
        const cachedData = weakRef.deref();
        if (cachedData) {
            console.log(`从弱缓存中获取 ${key}`);
            return cachedData;
        } else {
            // 缓存项已被GC，需要重新计算
            weakCache.delete(key);
        }
    }
    console.log(`计算并缓存昂贵数据 ${key} 到弱缓存...`);
    const data = { /* 模拟昂贵计算结果 */ value: Math.random() + 100 };
    weakCache.set(key, new WeakRef(data)); // 存储弱引用
    return data;
}

let weakData1 = getWeaklyCachedData("weakItemA"); // 计算并缓存
let weakData2 = getWeaklyCachedData("weakItemB"); // 计算并缓存

weakData1 = null; // 移除对 weakData1 的强引用

// 此时，如果GC运行，weakItemA 的数据可能会被回收
// 再次调用 getWeaklyCachedData("weakItemA") 可能导致重新计算
// global.gc(); // 如果在Node.js中，可以尝试手动GC
setTimeout(() => {
    console.log("n-----------------------------------------");
    console.log("检查弱缓存项：");
    getWeaklyCachedData("weakItemA"); // 可能会重新计算
    getWeaklyCachedData("weakItemB"); // 应该仍然从缓存获取，因为 weakData2 仍被强引用
}, 50);

    这个例子展示了WeakRef如何允许缓存项在外部不再被强引用时，在内存压力下被GC自动清理。

2.5 WeakRef的局限性

WeakRef虽然有用，但它有一个根本性的局限：它只能告诉你一个对象是否“仍然活着”。它不能在对象被GC时触发任何清理动作。如果你的目标是当JS对象被回收时，同时释放其关联的外部资源，那么仅仅依靠WeakRef是不够的。这就是FinalizationRegistry发挥作用的地方。

3. 生命周期监听与资源清理利器：FinalizationRegistry

FinalizationRegistry是ES2021引入的另一个强大API，它专门用于解决WeakRef无法解决的问题：在对象被垃圾回收时执行一个清理回调函数。

3.1 FinalizationRegistry是什么？

FinalizationRegistry提供了一种机制，允许你注册一个回调函数（cleanupCallback），当一个你指定的目标对象（target）被垃圾回收时，这个回调函数就会被调用。这个回调函数可以用来释放与target对象关联的外部资源。

3.2 核心概念与创建

要创建一个FinalizationRegistry实例，你需要提供一个cleanupCallback函数作为参数：

const registry = new FinalizationRegistry((heldValue) => {
    // 当一个被注册的对象被GC时，这个回调会被调用
    console.log(`FinalizationRegistry: 对象已被GC，执行清理操作。heldValue:`, heldValue);
    // 在这里释放外部资源
});

cleanupCallback会接收一个参数：heldValue。这个heldValue是在注册时与目标对象关联的值，它包含了执行清理操作所需的信息。

3.3 register()方法：关联目标对象与清理数据

要开始监听一个对象的GC事件，你需要使用FinalizationRegistry实例的register()方法：

registry.register(target, heldValue, [unregisterToken]);
  • target：这是你希望监听其生命周期的JavaScript对象。当这个target对象被垃圾回收时，cleanupCallback就会被触发。target对象本身不能是原始值（如字符串、数字、布尔值、null、undefined或Symbol）。
  • heldValue：这是一个任意值，当cleanupCallback被调用时，它将作为参数传递给回调函数。heldValue通常包含执行清理操作所需的所有信息（例如文件句柄ID、数据库连接字符串等）。至关重要的一点是：heldValue绝对不能强引用target对象，或任何能够间接强引用target的对象。 如果heldValue强引用了target，那么target将永远不会被GC，导致内存泄露，并且cleanupCallback永远不会被调用。
  • unregisterToken (可选)：这是一个可选的参数，可以是一个任意对象。如果你提供了unregisterToken，你就可以在稍后使用它来手动取消对target对象的监听。这个unregisterToken也必须是一个不强引用target的对象。如果未提供，则无法手动注销。

示例：基本注册

const myCleanupCallback = (value) => {
    console.log(`清理回调被触发！需要清理的资源ID是: ${value.resourceId} (类型: ${value.type})`);
    // 在这里执行真实的资源释放逻辑，比如关闭文件句柄，释放内存等
};

const resourceRegistry = new FinalizationRegistry(myCleanupCallback);

let fileObject = { path: "/tmp/data.log", description: "日志文件" };
const fileResourceId = "file_12345";

// 注册 fileObject，当它被GC时，执行 myCleanupCallback，并传递 { resourceId: fileResourceId, type: 'file' }
resourceRegistry.register(fileObject, { resourceId: fileResourceId, type: 'file' });

console.log("文件对象已注册到 FinalizationRegistry。");

// 移除对 fileObject 的强引用，使其有资格被GC
fileObject = null;

// 在Node.js中，可以尝试手动触发GC来观察效果
// global.gc(); // 运行 `node --expose-gc your_script.js`

// 由于清理回调是异步的，我们需要等待一段时间才能看到效果
setTimeout(() => {
    console.log("等待一段时间后...");
    // 如果GC已经运行，并且回调已经被调度，这里可能会看到清理信息
}, 500);

// 另一个对象，例如一个数据库连接
let dbConnection = { host: "localhost", user: "admin" };
const dbConnectionId = "db_conn_67890";
resourceRegistry.register(dbConnection, { resourceId: dbConnectionId, type: 'database' });
console.log("数据库连接对象已注册到 FinalizationRegistry。");
dbConnection = null;

setTimeout(() => {
    console.log("再次等待一段时间...");
}, 1000);

运行上述代码，如果GC被触发，您会看到myCleanupCallback被执行，并打印出相应的清理信息。

3.4 unregister()方法：手动取消监听

如果你不再需要FinalizationRegistry来监听某个对象，或者你已经显式地释放了关联的外部资源，你可以使用unregister()方法来取消注册。这需要你在register()时提供一个unregisterToken。

const manualCleanupCallback = (value) => {
    console.log(`手动清理回调被触发！资源ID: ${value.id}`);
};
const manualRegistry = new FinalizationRegistry(manualCleanupCallback);

let objToMonitor = { value: "important data" };
const unregisterToken = {}; // 必须是独立的对象，不能强引用 objToMonitor
manualRegistry.register(objToMonitor, { id: "monitor_A" }, unregisterToken);
console.log("对象 objToMonitor 已注册，带有 unregisterToken。");

// 假设我们在某个时刻手动清理了与 objToMonitor 相关的资源
console.log("手动取消注册 objToMonitor...");
manualRegistry.unregister(unregisterToken);

// 此时，即使 objToMonitor 被GC，manualCleanupCallback 也不会被触发
objToMonitor = null;

// 尝试触发GC，并等待。不会看到 'monitor_A' 的清理信息。
// global.gc();
setTimeout(() => {
    console.log("等待一段时间，观察是否触发 'monitor_A' 的清理回调...");
}, 500);

// 再注册一个没有 unregisterToken 的对象
let anotherObj = { value: "another data" };
manualRegistry.register(anotherObj, { id: "monitor_B" });
console.log("对象 anotherObj 已注册，没有 unregisterToken。");
anotherObj = null;

// 'monitor_B' 最终会触发清理回调（如果GC运行）
// global.gc();
setTimeout(() => {
    console.log("等待一段时间，观察是否触发 'monitor_B' 的清理回调...");
}, 1000);

3.5 cleanupCallback的特性与重要注意事项

理解FinalizationRegistry的关键在于理解其回调函数的特性：

  1. 异步执行：cleanupCallback不会在target对象被GC的精确时刻同步执行。相反，它会在target被GC后的某个不确定但通常较短的时间内，被异步调度执行。这意味着你不能依赖它来立即释放关键资源。
  2. 不保证执行：FinalizationRegistry的回调是“尽力而为”的。在某些情况下，它可能永远不会被调用：
    • 进程终止：如果JavaScript进程在target对象被GC但cleanupCallback尚未执行之前就终止了，那么回调将永远不会运行。
    • 对象从未被GC：如果target对象从未变得不可达（例如，由于某种意外的强引用），或者GC从未运行（例如，程序内存充足，没有压力），那么回调也不会运行。
    • 内存压力：GC通常在内存压力较高时运行。在内存充裕的环境中，GC可能不经常运行，导致回调延迟很久才执行。
  3. 无序性：如果你注册了多个对象，并且它们都被GC了，你不能保证它们的cleanupCallback会按照注册顺序或GC顺序执行。

  4. heldValue的安全性：再次强调，heldValue必须是原始值或一个独立的对象，它不能强引用target对象。如果heldValue强引用了target，那么target将永远不会被GC，从而导致cleanupCallback永远不会被调用，形成内存泄露。

    • 错误示例（反模式）：

      const antiPatternRegistry = new FinalizationRegistry((heldValue) => {
    console.error("这个清理回调永远不会触发！");
});

let badObject = { data: "Bad object" };
// 错误：heldValue 强引用了 badObject
// badObject 永远不会被GC
antiPatternRegistry.register(badObject, badObject); // 这是一个严重错误！

badObject = null; // 试图解除强引用，但无效，因为 heldValue 仍然强引用着它
// global.gc(); // 即使手动GC，也不会触发
setTimeout(() => {
    console.log("等待，但不会看到 badObject 的清理信息...");
}, 1000);

    • 正确示例：

      const correctRegistry = new FinalizationRegistry((heldValue) => {
    console.log(`清理回调触发：资源ID ${heldValue.id}`);
});

let goodObject = { data: "Good object" };
// 正确：heldValue 只是一个包含 ID 的独立对象，不引用 goodObject
correctRegistry.register(goodObject, { id: "good_resource_1" });

goodObject = null; // 解除强引用，goodObject 有资格被GC
// global.gc();
setTimeout(() => {
    console.log("等待，应该会看到 good_resource_1 的清理信息...");
}, 1000);
  5. 回调不能“复活”对象：cleanupCallback在target对象已经被GC之后才被调度。理论上，即使你能在回调中以某种方式重新获取到target对象（这本身就是反模式，且通常不可能），你也不应该尝试重新建立对它的强引用，因为这会破坏GC的内部状态，可能导致不可预测的行为。

4. WeakRef与FinalizationRegistry的异同与协同

理解WeakRef和FinalizationRegistry各自的定位和它们之间的关系至关重要。它们都是基于弱引用语义的高级内存管理工具，但解决的问题不同。

4.1 异同点表格

特性 WeakRef FinalizationRegistry
目的 检查对象是否仍然存活，获取目标对象的弱引用。 在对象被GC时执行预定义的清理操作。
触发时机 任何时候可以调用deref()方法检查目标对象存活状态。 目标对象被GC后，由JavaScript引擎异步调度cleanupCallback。
回调函数 无直接回调机制。通过deref()的返回值（对象或undefined）来判断。 有一个cleanupCallback，接收heldValue作为参数。
是否阻止GC 不阻止目标对象被GC。 注册本身不阻止目标对象被GC。但注册时提供的heldValue绝对不能强引用目标对象，否则会阻止GC。
主要应用 实现可自动清除的缓存、对象池、软引用语义。 自动释放与JavaScript对象关联的外部（Native）资源、监听对象生命周期结束。
返回值 deref()返回目标对象或undefined。 构造函数返回FinalizationRegistry实例。register()和unregister()无返回值。
保证性 deref()是同步且可靠的（如果对象存活）。 cleanupCallback是异步且不保证执行的。

4.2 协同使用场景

尽管WeakRef和FinalizationRegistry解决的问题不同，但它们都围绕“弱引用”这一核心概念。在某些复杂场景下，它们可能会被一起使用，但通常不是直接协同作用于同一个目标对象。

例如，你可能在FinalizationRegistry的heldValue中包含一个WeakRef，用于在清理时检查某个其他相关对象的存活状态。但这比较罕见，且需要非常谨慎地设计，以避免引入新的强引用循环。

更常见的情况是，你可能使用WeakRef来实现一个普通的、可以自动清除的内存缓存，而使用FinalizationRegistry来管理那些与外部资源关联的JavaScript对象。它们服务于不同的目的，但都是为了更精细地控制JavaScript的内存行为。

5. 深入实践：外部资源清理的典型场景

现在，让我们通过具体的代码示例来深入探讨如何利用FinalizationRegistry来管理外部资源。

5.1 场景一：模拟文件句柄的自动关闭

假设我们正在开发一个Node.js应用程序，它需要处理大量的临时文件。我们希望当代表文件句柄的JavaScript对象不再被使用时，其对应的文件句柄能够自动关闭，而无需手动调用close()。

// 模拟一个外部文件系统API
const NativeFileSystem = {
    openFiles: new Map(), // 存储打开的文件句柄
    nextFileId: 1,

    open(path) {
        const fileId = `FILE_${this.nextFileId++}`;
        this.openFiles.set(fileId, { path, createdAt: new Date() });
        console.log(`[NativeFS] 文件句柄 ${fileId} 已打开：${path}`);
        return fileId; // 返回一个 Native 资源ID
    },

    close(fileId) {
        if (this.openFiles.has(fileId)) {
            this.openFiles.delete(fileId);
            console.log(`[NativeFS] 文件句柄 ${fileId} 已关闭。`);
            return true;
        }
        console.warn(`[NativeFS] 尝试关闭不存在的文件句柄：${fileId}`);
        return false;
    },

    listOpenFiles() {
        console.log(`[NativeFS] 当前打开的文件数量: ${this.openFiles.size}`);
        this.openFiles.forEach((info, id) => console.log(`  - ${id}: ${info.path}`));
    }
};

// 1. 定义一个 FinalizationRegistry 实例
// 其 cleanupCallback 负责调用 NativeFileSystem.close()
const fileHandleRegistry = new FinalizationRegistry((fileId) => {
    console.log(`n--- FinalizationRegistry 回调触发 ---`);
    console.log(`文件对象已被GC，正在尝试关闭文件句柄: ${fileId}`);
    NativeFileSystem.close(fileId);
    console.log(`--- FinalizationRegistry 回调结束 ---n`);
});

// 2. 封装文件句柄的 JavaScript 类
class ManagedFileHandle {
    constructor(path) {
        // 实际的文件句柄 ID，由 Native 接口返回
        this.nativeFileId = NativeFileSystem.open(path);
        this.path = path;

        // 在创建 ManagedFileHandle 实例时，将其注册到 FinalizationRegistry
        // heldValue 传递 nativeFileId，因为这是 cleanupCallback 需要的信息
        // unregisterToken 可以是 this，因为 this 不会阻止自身的GC，但此处用单独对象更安全
        fileHandleRegistry.register(this, this.nativeFileId, this); // 使用 this 作为 unregisterToken
        console.log(`JS对象 ManagedFileHandle(${this.nativeFileId}) 已注册。`);
    }

    read() {
        if (!NativeFileSystem.openFiles.has(this.nativeFileId)) {
            console.warn(`文件句柄 ${this.nativeFileId} 已关闭或不存在，无法读取。`);
            return;
        }
        console.log(`读取文件 ${this.path} (句柄: ${this.nativeFileId})...`);
        // 模拟文件读取操作
    }

    // 显式关闭方法，仍然推荐提供
    close() {
        if (NativeFileSystem.openFiles.has(this.nativeFileId)) {
            console.log(`显式关闭文件句柄 ${this.nativeFileId}。`);
            NativeFileSystem.close(this.nativeFileId);
            // 手动关闭后，我们也应该从 FinalizationRegistry 中注销
            fileHandleRegistry.unregister(this); // 使用之前注册的 token
            this.nativeFileId = null; // 清除引用
        } else {
            console.warn(`文件句柄 ${this.nativeFileId} 已经关闭或不存在。`);
        }
    }
}

console.log("--- 场景一：模拟文件句柄的自动关闭 ---");

// 示例 1: 自动关闭 (通过GC)
console.log("n--- 示例 1: 自动关闭 ---");
let file1 = new ManagedFileHandle("log.txt");
file1.read();
NativeFileSystem.listOpenFiles();

file1 = null; // 移除强引用，允许 file1 对象被GC

// 触发GC并等待回调
// 在Node.js中运行 `node --expose-gc your_script.js`
// global.gc(); // 手动触发GC，观察效果
setTimeout(() => {
    console.log("n等待GC和FinalizationRegistry回调...");
    NativeFileSystem.listOpenFiles();
}, 200); // 适当延迟

// 示例 2: 手动关闭 (显式调用 close())
console.log("n--- 示例 2: 手动关闭 ---");
let file2 = new ManagedFileHandle("config.json");
file2.read();
NativeFileSystem.listOpenFiles();
file2.close(); // 显式关闭
NativeFileSystem.listOpenFiles();

file2 = null; // 移除强引用

// 触发GC并等待回调。由于已手动关闭并注销，不会再触发 file2 的清理回调。
// global.gc();
setTimeout(() => {
    console.log("n等待GC和FinalizationRegistry回调 (file2 不应触发)...");
    NativeFileSystem.listOpenFiles();
}, 400); // 再次延迟

在上述代码中：

  1. NativeFileSystem模拟了一个底层的文件系统API，它管理着真正的文件句柄。
  2. fileHandleRegistry是FinalizationRegistry实例，其cleanupCallback负责调用NativeFileSystem.close()。
  3. ManagedFileHandle类封装了文件句柄。在构造函数中，它获取一个nativeFileId并将其this实例注册到fileHandleRegistry，同时将nativeFileId作为heldValue。
  4. 当file1对象被设置为null后，它变得不可达。当GC运行时，file1对象会被回收，进而触发fileHandleRegistry的cleanupCallback，nativeFileId被传入，最终NativeFileSystem.close()被调用，文件句柄被释放。
  5. file2演示了显式close()。当close()被调用时，我们主动调用NativeFileSystem.close()并从FinalizationRegistry中unregister()，确保GC发生时不会再次尝试关闭已经关闭的资源。

5.2 场景二：模拟数据库连接的自动释放

与文件句柄类似，数据库连接也是典型的需要清理的外部资源。

// 模拟一个外部数据库连接池
const NativeDatabase = {
    connections: new Map(),
    nextConnectionId: 1,

    connect(config) {
        const connId = `DB_CONN_${this.nextConnectionId++}`;
        this.connections.set(connId, { config, status: 'open', createdAt: new Date() });
        console.log(`[NativeDB] 数据库连接 ${connId} 已建立到 ${config.host}:${config.port}`);
        return connId;
    },

    disconnect(connId) {
        if (this.connections.has(connId)) {
            const conn = this.connections.get(connId);
            conn.status = 'closed';
            this.connections.delete(connId);
            console.log(`[NativeDB] 数据库连接 ${connId} 已关闭。`);
            return true;
        }
        console.warn(`[NativeDB] 尝试关闭不存在的数据库连接：${connId}`);
        return false;
    },

    query(connId, sql) {
        if (!this.connections.has(connId) || this.connections.get(connId).status === 'closed') {
            console.error(`[NativeDB] 连接 ${connId} 已关闭或不存在，无法执行查询。`);
            throw new Error('Connection closed');
        }
        console.log(`[NativeDB] 连接 ${connId} 执行查询: "${sql}"`);
        return `Query result for ${sql}`;
    },

    listOpenConnections() {
        console.log(`[NativeDB] 当前打开的连接数量: ${this.connections.size}`);
        this.connections.forEach((info, id) => console.log(`  - ${id}: ${info.config.host} (${info.status})`));
    }
};

// 1. 定义 FinalizationRegistry 实例来管理数据库连接
const dbConnectionRegistry = new FinalizationRegistry((connId) => {
    console.log(`n--- FinalizationRegistry 回调触发 ---`);
    console.log(`数据库连接对象已被GC，正在尝试关闭连接: ${connId}`);
    NativeDatabase.disconnect(connId);
    console.log(`--- FinalizationRegistry 回调结束 ---n`);
});

// 2. 封装数据库连接的 JavaScript 类
class DatabaseConnection {
    constructor(config) {
        this.nativeConnectionId = NativeDatabase.connect(config);
        this.config = config;

        // 注册到 FinalizationRegistry
        dbConnectionRegistry.register(this, this.nativeConnectionId, this); // 使用 this 作为 unregisterToken
        console.log(`JS对象 DatabaseConnection(${this.nativeConnectionId}) 已注册。`);
    }

    async executeQuery(sql) {
        if (!this.nativeConnectionId) {
            throw new Error("连接已关闭，无法执行查询。");
        }
        return NativeDatabase.query(this.nativeConnectionId, sql);
    }

    close() {
        if (this.nativeConnectionId && NativeDatabase.connections.has(this.nativeConnectionId)) {
            console.log(`显式关闭数据库连接 ${this.nativeConnectionId}。`);
            NativeDatabase.disconnect(this.nativeConnectionId);
            dbConnectionRegistry.unregister(this); // 从注册表中注销
            this.nativeConnectionId = null;
        } else {
            console.warn(`连接 ${this.nativeConnectionId} 已经关闭或不存在。`);
        }
    }
}

console.log("n--- 场景二：模拟数据库连接的自动释放 ---");

// 示例 1: 自动释放 (通过GC)
console.log("n--- 示例 1: 自动释放 ---");
let db1 = new DatabaseConnection({ host: "db1.example.com", port: 5432 });
db1.executeQuery("SELECT * FROM users;");
NativeDatabase.listOpenConnections();

db1 = null; // 解除强引用
// global.gc();
setTimeout(() => {
    console.log("n等待GC和FinalizationRegistry回调...");
    NativeDatabase.listOpenConnections();
}, 200);

// 示例 2: 显式释放
console.log("n--- 示例 2: 显式释放 ---");
let db2 = new DatabaseConnection({ host: "db2.example.com", port: 3306 });
db2.executeQuery("INSERT INTO products VALUES (...);");
NativeDatabase.listOpenConnections();
db2.close(); // 显式关闭
NativeDatabase.listOpenConnections();

db2 = null;
// global.gc();
setTimeout(() => {
    console.log("n等待GC和FinalizationRegistry回调 (db2 不应触发)...");
    NativeDatabase.listOpenConnections();
}, 400);

这个例子与文件句柄的场景类似，再次强调了FinalizationRegistry作为一种“安全网”的作用。它确保即使开发者忘记显式调用close()，底层资源也能在JavaScript对象被GC时得到释放。

5.3 场景三：WebAssembly内存或其他Native资源

概念性讨论：

  • WebAssembly (WASM) 内存：当JavaScript代码通过WebAssembly模块分配了大量内存（例如，一个大的ArrayBuffer，它实际上指向WASM堆上的内存），并且这个ArrayBuffer的JavaScript包装对象被GC时，我们可能希望WASM模块内部的相应内存区域也能被释放。FinalizationRegistry可以监听这个ArrayBuffer（或其包装对象），并在它被GC时调用WASM的内存释放函数。
  • C++ 对象指针：在某些Node.js N-API或WebIDL绑定场景中，JavaScript对象可能持有指向底层C++对象的指针。当JavaScript对象被GC时，需要通过这个指针调用C++侧的析构函数来释放C++对象所占用的内存。FinalizationRegistry是实现这一“析构语义”的理想工具。
  • 操作系统级资源：如互斥锁、信号量、图形上下文等。如果JavaScript对象持有对这些资源的引用，FinalizationRegistry可以确保在对象生命周期结束时，这些资源被正确释放或解除锁定。

这些场景的共同特点是：JavaScript对象是底层Native资源的“代理”。当代理对象消失时，它所代理的真实Native资源也应该被释放。FinalizationRegistry提供了这种自动化的“代理对象死亡 -> 真实资源清理”的机制。

6. 使用FinalizationRegistry的最佳实践与注意事项

FinalizationRegistry是一个强大的工具，但它的异步性和不确定性要求我们谨慎使用。遵循最佳实践可以帮助我们避免潜在的问题。

6.1 heldValue的选择

heldValue是FinalizationRegistry的核心机制之一，它决定了cleanupCallback能够获取哪些信息来执行清理。

  • 优先使用原始值：字符串、数字、布尔值、Symbol。这些值是不可变的，并且不会强引用任何其他对象，因此是最安全的。 
    registry.register(someObj, "resource_id_123");
  • 使用不强引用target的独立对象：如果需要传递多个信息，可以创建一个包含这些信息的独立对象。这个对象不能直接或间接引用target对象。 
    const resourceInfo = { id: "resource_id_456", type: "network_socket", timestamp: Date.now() };
registry.register(someObj, resourceInfo);
  • 避免在heldValue中包含WeakRef到target：虽然技术上可行，但通常没有必要，并且可能增加复杂性。cleanupCallback的调用本身就意味着target已被GC。
  • 避免在heldValue中包含任何可能复活target的信息：例如，一个包含target的WeakRef，然后试图在回调中deref()并重新存储它，这会是严重的反模式。

6.2 避免“复活”对象（Zombie Objects）

cleanupCallback在target对象被GC后才会被调度执行。因此，在cleanupCallback内部，你不应该尝试重新建立对target对象的强引用。这样做可能会导致：

  • 垃圾回收器内部状态损坏：试图“复活”一个已被回收的对象可能会破坏GC的内部逻辑。
  • 不可预测的行为：即使技术上可能，也可能导致target对象处于一种不一致的状态。
  • 内存泄露：如果成功复活，那么target对象将再次变得可达，永远不会被完全清理。

FinalizationRegistry的设计理念是，当cleanupCallback被调用时，target对象已经死了。heldValue中只应包含清理资源所需的信息，而不再关心target对象本身。

6.3 异步性与不确定性

这是FinalizationRegistry最重要的特性，也是其局限性所在：

  • 不要依赖精确时机：清理回调可能在GC后立即运行，也可能延迟很长时间。你不能假设它会在某个精确的时间点执行。
  • 不保证执行：如前所述，进程终止或内存压力不足都可能导致回调永不运行。这意味着FinalizationRegistry不适合管理那些“必须”被释放的关键资源。
  • “尽力而为”的机制：将其视为一个“安全网”或“最后一道防线”，而不是主要的资源管理策略。

6.4 错误处理

cleanupCallback中的任何未捕获异常都将传播到事件循环，可能导致应用程序崩溃（在Node.js中）或在浏览器中显示错误。因此，在cleanupCallback内部执行的清理逻辑应该健壮，并包含适当的错误处理：

const safeRegistry = new FinalizationRegistry((resourceId) => {
    try {
        console.log(`尝试清理资源: ${resourceId}`);
        // 模拟可能出错的清理操作
        if (Math.random() > 0.8) {
            throw new Error(`清理资源 ${resourceId} 失败！`);
        }
        console.log(`资源 ${resourceId} 清理成功。`);
    } catch (error) {
        console.error(`清理资源 ${resourceId} 时发生错误:`, error.message);
        // 可以将错误记录到日志系统，或尝试回退机制
    }
});

6.5 性能考量

  • 注册开销：每次调用register()都会在FinalizationRegistry内部创建一个新的弱引用，并维护一个内部表。这会带来轻微的开销，但通常可以忽略不计。
  • 回调执行开销：cleanupCallback的执行本身需要CPU时间。如果注册了大量对象，并且它们同时被GC，可能会导致短时间的CPU峰值，尤其是在GC周期中。
  • GC复杂性：引入弱引用和终结器可能会使GC的内部算法稍微复杂一些，因为它需要跟踪额外的弱引用和调度回调。但现代JavaScript引擎已经对此进行了优化。
    总的来说，对于大多数合理的用例，FinalizationRegistry带来的性能开销是可接受的。

6.6 何时不使用FinalizationRegistry

尽管FinalizationRegistry功能强大，但并非所有场景都适用：

  • 显式资源管理是首选：当资源有明确的生命周期，并且可以可靠地通过try...finally、async/await结合finally块、或者using声明（未来的提案）等方式进行显式管理时，始终优先使用这些方法。显式管理提供确定性和即时性。
  • 需要精确时机释放资源时：如果一个资源非常稀缺，必须在不再需要时立即释放，那么FinalizationRegistry的异步和不确定性使其不适合。例如，实时游戏的网络连接，或关键的UI锁。
  • 资源不与特定JavaScript对象强绑定时：如果资源是全局的或由一个中央管理器统一维护，那么可能不需要FinalizationRegistry。

FinalizationRegistry最适合作为补充机制，为那些“可能被遗忘”的外部资源提供一个“安全网”，或者用于实现“资源在JS对象死亡时自动清理”的语义。

7. 综合示例：构建一个健壮的资源管理系统

让我们将上述概念整合起来，构建一个更通用的资源管理系统，可以自动清理不同类型的Native资源。

// 模拟一个通用的 Native 资源管理层
const NativeResourceManager = {
    activeResources: new Map(), // 存储活跃的 Native 资源实例
    nextResourceId: 1,

    allocate(type, config) {
        const resourceId = `${type.toUpperCase()}_${this.nextResourceId++}`;
        const resource = { id: resourceId, type, config, status: 'allocated', createdAt: new Date() };
        this.activeResources.set(resourceId, resource);
        console.log(`[NativeManager] 分配 ${type} 资源: ${resourceId} (配置: ${JSON.stringify(config)})`);
        return resourceId;
    },

    release(resourceId) {
        if (this.activeResources.has(resourceId)) {
            const resource = this.activeResources.get(resourceId);
            resource.status = 'released';
            this.activeResources.delete(resourceId);
            console.log(`[NativeManager] 释放 ${resource.type} 资源: ${resourceId}`);
            return true;
        }
        console.warn(`[NativeManager] 尝试释放不存在的资源: ${resourceId}`);
        return false;
    },

    listActiveResources() {
        console.log(`[NativeManager] 当前活跃资源数量: ${this.activeResources.size}`);
        this.activeResources.forEach((info, id) => console.log(`  - ${id} (${info.type}): ${info.status}`));
    }
};

// 1. 定义一个通用的 FinalizationRegistry 来处理所有资源类型
const globalResourceRegistry = new FinalizationRegistry((resourceId) => {
    console.log(`n--- FinalizationRegistry 回调触发 ---`);
    console.log(`JS对象已被GC，正在尝试自动释放资源: ${resourceId}`);
    NativeResourceManager.release(resourceId);
    console.log(`--- FinalizationRegistry 回调结束 ---n`);
});

// 2. 抽象的 JavaScript 资源基类
class ManagedResource {
    constructor(type, config) {
        if (new.target === ManagedResource) {
            throw new Error("ManagedResource 是抽象类，不能直接实例化。");
        }
        this.type = type;
        this.config = config;
        this.nativeResourceId = NativeResourceManager.allocate(type, config);

        // 注册到全局 FinalizationRegistry
        globalResourceRegistry.register(this, this.nativeResourceId, this); // 使用 this 作为 unregisterToken
        console.log(`JS对象 ManagedResource(${this.nativeResourceId}) 已注册。`);
    }

    // 显式释放方法，推荐调用
    release() {
        if (this.nativeResourceId && NativeResourceManager.activeResources.has(this.nativeResourceId)) {
            console.log(`显式释放资源 ${this.nativeResourceId} (${this.type})。`);
            NativeResourceManager.release(this.nativeResourceId);
            globalResourceRegistry.unregister(this); // 从注册表中注销
            this.nativeResourceId = null;
        } else {
            console.warn(`资源 ${this.nativeResourceId} 已经释放或不存在。`);
        }
    }

    // 可以在子类中实现具体操作
    performOperation() {
        throw new Error("子类必须实现 performOperation 方法。");
    }
}

// 3. 具体资源类：文件句柄
class FileHandle extends ManagedResource {
    constructor(path) {
        super("file", { path });
        this.path = path;
    }

    performOperation() {
        if (!this.nativeResourceId || !NativeResourceManager.activeResources.has(this.nativeResourceId)) {
            console.warn(`文件句柄 ${this.nativeResourceId} 已关闭或不存在，无法读取。`);
            return;
        }
        console.log(`文件句柄 ${this.nativeResourceId} (路径: ${this.path}) 正在读取数据...`);
    }
}

// 4. 具体资源类：网络连接
class NetworkConnection extends ManagedResource {
    constructor(host, port) {
        super("network", { host, port });
        this.host = host;
        this.port = port;
    }

    performOperation() {
        if (!this.nativeResourceId || !NativeResourceManager.activeResources.has(this.nativeResourceId)) {
            console.warn(`网络连接 ${this.nativeResourceId} 已关闭或不存在，无法发送数据。`);
            return;
        }
        console.log(`网络连接 ${this.nativeResourceId} (目标: ${this.host}:${this.port}) 正在发送数据...`);
    }
}

console.log("--- 综合示例：构建一个健壮的资源管理系统 ---");

// 示例 1: 多个资源，部分自动释放，部分手动释放
console.log("n--- 示例 1: 混合释放策略 ---");

let fileA = new FileHandle("/tmp/report.csv");
fileA.performOperation();
NativeResourceManager.listActiveResources();

let conn1 = new NetworkConnection("api.example.com", 8080);
conn1.performOperation();
NativeResourceManager.listActiveResources();

let fileB = new FileHandle("/tmp/temp.log");
fileB.performOperation();
NativeResourceManager.listActiveResources();

// 手动释放 conn1
conn1.release();
NativeResourceManager.listActiveResources();

// 解除强引用，让 fileA 和 fileB 有资格被GC
fileA = null;
fileB = null;

// global.gc(); // 触发GC (如果是在Node.js中)

setTimeout(() => {
    console.log("n等待GC和FinalizationRegistry回调...");
    NativeResourceManager.listActiveResources();
}, 500); // 适当延迟以观察GC效果

这个综合示例展示了如何构建一个更抽象、更通用的资源管理框架。ManagedResource作为基类，在构造函数中自动将实例注册到globalResourceRegistry。子类（如FileHandle和NetworkConnection）只需关注其特定的业务逻辑。无论是手动调用release()还是依赖GC自动清理，都能确保底层Native资源得到妥善处理。

8. 弱引用与终结器：现代JavaScript内存管理新篇章

WeakRef和FinalizationRegistry为JavaScript带来了更细粒度的内存管理能力，弥补了传统垃圾回收机制在处理与外部Native资源关联的JavaScript对象时的不足。它们使得开发者能够以一种“尽力而为”的方式，在JavaScript对象被垃圾回收时自动释放其关联的外部资源，从而有效防止资源泄露。

理解WeakRef用于查询对象存活状态，而FinalizationRegistry用于在对象死亡时执行清理，是正确使用它们的关键。同时，必须深刻理解FinalizationRegistry的异步性、不确定性以及heldValue的安全性限制。在大多数情况下，显式资源管理仍然是首选方案，但FinalizationRegistry为复杂场景和作为“安全网”提供了强大而优雅的后备方案，标志着现代JavaScript在内存管理方面迈出了重要一步。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注