什么是JavaScript的WeakRef和FinalizationRegistry，以及它们如何协助管理对象生命周期和资源清理？-js教程-PHP中文网

WeakRef和FinalizationRegistry提供弱引用与对象回收后回调机制，解决内存泄漏问题。WeakRef允许引用对象而不阻止其被垃圾回收，适用于缓存等场景避免内存泄漏；FinalizationRegistry在对象被回收后执行清理操作，用于释放文件句柄、数据库连接等外部资源。两者结合实现更精细的内存与资源管理，提升JavaScript在复杂应用中的性能与可靠性。

什么是javascript的weakref和finalizationregistry，以及它们如何协助管理对象生命周期和资源清理？

WeakRef

登录后复制

允许你持有对一个对象的弱引用，这意味着这个引用不会阻止垃圾回收器回收该对象。而

FinalizationRegistry

登录后复制

则提供了一种机制，让你能在注册的对象被垃圾回收后执行一个清理回调函数。它们共同为JavaScript开发者提供了一种更精细地管理对象生命周期和外部资源清理的手段，尤其是在处理缓存、大型DOM结构或需要与外部系统交互的场景中，能有效避免内存泄漏和资源浪费。

解决方案

在JavaScript的世界里，内存管理一直是个隐形的战场。我们都知道垃圾回收器（GC）会自动帮我们清理不再使用的对象，但有时候，这种“自动”并非总是我们想要的全部。

WeakRef

登录后复制

和

FinalizationRegistry

登录后复制

的出现，就是为了在GC的强大能力之上，提供一些更细致、更可控的工具。

WeakRef

登录后复制

，顾名思义，就是“弱引用”。平时我们创建的对象引用都是强引用，只要有一个强引用存在，对象就不会被GC回收。但

WeakRef

登录后复制

不同，它持有的引用不会阻止对象被GC。这在什么场景下有用呢？想想看，你可能有一个大型缓存，里面存储了许多计算结果或DOM节点。如果你用强引用来缓存它们，即使这些结果或DOM节点在其他地方已经不再被使用，缓存的存在也会阻止它们被回收，最终可能导致内存爆炸。

一个

WeakRef

登录后复制

实例是通过

new WeakRef(obj)

登录后复制

创建的。要获取它引用的对象，你需要调用

weakRef.deref()

登录后复制

。如果对象已经被回收了，

deref()

登录后复制

就会返回

undefined

登录后复制

。

立即学习“Java免费学习笔记（深入）”；

let obj = { name: "我是一个对象" };
let weakRef = new WeakRef(obj);

// 此时，obj仍然存在，weakRef.deref() 会返回 obj
console.log(weakRef.deref()); // { name: "我是一个对象" }

// 将 obj 设置为 null，解除强引用
obj = null;

// 在某个不确定的时间点，GC可能会回收原来的对象
// 此时 weakRef.deref() 可能会返回 undefined
// 实际测试时，可能需要等待一段时间或强制GC（如果环境允许）才能看到效果
setTimeout(() => {
    console.log(weakRef.deref()); // 可能是 undefined
}, 1000);

登录后复制

而

FinalizationRegistry

登录后复制

呢，它更像是一个“善后处理”的登记处。它允许你注册一个对象和一个关联的“持标”（token），当这个对象被GC回收时，

FinalizationRegistry

登录后复制

就会执行一个你提供的回调函数，并把这个持标传给回调。这个持标可以是你用来识别被回收对象的任何数据，比如它的ID或者它所关联的外部资源句柄。

需要注意的是，

FinalizationRegistry

登录后复制

的回调执行是非确定性的。这意味着你无法精确控制它何时被调用，它只会在GC认为合适的时候执行。所以，它不适合用于那些必须立即释放的资源，比如文件写入操作的锁。但对于那些可以稍后清理的资源，比如关闭一个数据库连接或者释放一些非关键的内存，它就非常有用。

const registry = new FinalizationRegistry((value) => {
    console.log(`对象关联的资源 ${value} 已经被清理了！`);
    // 在这里执行清理操作，比如关闭文件句柄、网络连接等
});

let resourceId = 123;
let objToMonitor = { data: "一些数据" };

// 注册 objToMonitor，当它被GC时，会调用回调并传入 resourceId
registry.register(objToMonitor, resourceId);

// 解除 objToMonitor 的强引用
objToMonitor = null;

// 同样，回调的执行时间是不确定的，需要等待GC
setTimeout(() => {
    console.log("等待GC...");
}, 2000);

登录后复制

这两个API，一个解决了“不阻止回收”的问题，另一个解决了“回收后通知”的问题，它们共同构筑了JavaScript在内存管理方面更高级的控制能力。

为什么JavaScript需要WeakRef和FinalizationRegistry这样的高级内存管理工具？

说起来，JavaScript一直以来都被认为是“内存管理简单”的语言，因为有垃圾回收器嘛。但这种简单往往也意味着我们对内存的控制力不足。在很多复杂的应用场景，比如前端框架、大型数据可视化、或者那些需要频繁与原生API交互的Node.js服务里，传统的强引用机制很容易导致内存泄漏。想象一下，你渲染了一个巨大的DOM树，然后用户切换了页面，但因为某个地方还保留着对旧DOM节点的引用（比如一个事件监听器，或者一个缓存），这些节点就永远无法被回收。这不就是典型的内存泄漏吗？

WeakRef

登录后复制

解决的就是这种“我需要引用你，但又不想阻止你被回收”的矛盾。它让开发者可以在不干预GC决策的前提下，构建一些智能的缓存、映射表或者一些观察者模式，这些模式下的引用可以“自动消失”当被引用的对象不再被需要时。这有点像给GC一个暗示：“嘿，这个引用不重要，你可以随时回收它指向的对象。”

而

FinalizationRegistry

登录后复制

呢，它解决的是“对象被回收后我需要做点什么”的问题。在JavaScript里，对象本身通常只占用内存。但很多时候，一个JS对象会关联着一些外部资源，比如WebAssembly内存、文件句柄、数据库连接、WebGL纹理等等。这些外部资源可不是GC能管得了的。如果JS对象被回收了，但我们没有手动去释放这些外部资源，那就会造成资源泄漏，比如文件句柄一直开着，或者数据库连接一直占用着池子。

FinalizationRegistry

登录后复制

提供了一个相对优雅的机制，让我们可以“订阅”对象的回收事件，然后在回调中执行这些外部资源的清理工作。这比我们自己去维护一个复杂的生命周期管理系统要省心得多，虽然它的非确定性确实需要我们仔细考量其适用场景。

钉钉 AI 助理

钉钉AI助理汇集了钉钉AI产品能力，帮助企业迈入智能新时代。

查看详情

WeakRef在实际开发中如何避免内存泄漏并优化缓存策略？

WeakRef

登录后复制

在优化缓存策略和避免内存泄漏方面确实是把好手。最典型的场景就是构建一个“弱缓存”或者“弱映射”。

比如，你正在开发一个图片处理应用，需要对用户上传的图片进行各种变换（缩放、裁剪、滤镜）。每次变换都会生成一个新的图片对象。为了避免重复计算，你可能会想把这些变换结果缓存起来。如果用一个普通的

Map

登录后复制

来做缓存：

const strongCache = new Map();

function processImage(imageData) {
    // 假设 imageData 是一个复杂对象，代表原始图片
    const cacheKey = JSON.stringify(imageData); // 简化处理，实际可能用哈希
    if (strongCache.has(cacheKey)) {
        console.log("从强缓存中获取");
        return strongCache.get(cacheKey);
    }

    console.log("执行复杂图片处理...");
    const processedImage = { /* 复杂的处理结果 */ };
    strongCache.set(cacheKey, processedImage);
    return processedImage;
}

let img1 = { id: 1, data: "..." };
processImage(img1);
img1 = null; // 原始图片对象不再被引用

// 此时，即使 img1 已经 null 了，但 strongCache 仍然持有 processedImage 的引用，阻止其被GC
// 如果 processedImage 很大，这就会导致内存泄漏

登录后复制

这里的问题是，即使

img1

登录后复制

原始对象已经不再被使用，但

strongCache

登录后复制

仍然持有其处理结果

processedImage

登录后复制

的强引用。如果用户不断上传新图片，或者旧图片不再在UI上显示，这个缓存就会越来越大，最终耗尽内存。

有了

WeakRef

登录后复制

，我们可以这样优化：

const weakCache = new Map(); // 这里 Map 键是强引用，值是 WeakRef

function processImageWithWeakCache(imageData) {
    const cacheKey = JSON.stringify(imageData);
    if (weakCache.has(cacheKey)) {
        const cachedRef = weakCache.get(cacheKey);
        const cachedResult = cachedRef.deref();
        if (cachedResult) {
            console.log("从弱缓存中获取");
            return cachedResult;
        } else {
            // 对象已经被GC了，从缓存中移除旧的 WeakRef
            weakCache.delete(cacheKey);
        }
    }

    console.log("执行复杂图片处理...");
    const processedImage = { /* 复杂的处理结果，假设很大 */ };
    weakCache.set(cacheKey, new WeakRef(processedImage));
    return processedImage;
}

let img2 = { id: 2, data: "..." };
let result2 = processImageWithWeakCache(img2); // 第一次处理并缓存
console.log(result2);

// 解除对 img2 和 result2 的强引用
img2 = null;
result2 = null;

// 此时，如果 GC 运行，并且没有其他强引用指向 processedImage，
// 那么 weakCache 中对应的 WeakRef 就会指向 undefined。
// 下次访问时，会被清理掉。
setTimeout(() => {
    console.log("检查弱缓存状态...");
    const cacheKey = JSON.stringify({ id: 2, data: "..." });
    const cachedRef = weakCache.get(cacheKey);
    if (cachedRef) {
        console.log("缓存中仍有引用:", cachedRef.deref()); // 可能是 undefined
    } else {
        console.log("缓存中已无此项。");
    }
}, 1000);

登录后复制

通过使用

WeakRef

登录后复制

，当

processedImage

登录后复制

在其他地方不再被强引用时，即使

weakCache

登录后复制

中还存在一个

WeakRef

登录后复制

，它也不会阻止

processedImage

登录后复制

被GC回收。这样，缓存就能“自适应”地清理那些不再需要的条目，从而有效避免内存泄漏，并优化了内存使用。当然，这里

Map

登录后复制

的键仍然是强引用，如果键本身也是对象，你可能需要

WeakMap

登录后复制

来实现更彻底的弱引用缓存。

FinalizationRegistry如何确保外部资源（如文件句柄、网络连接）得到可靠清理？

FinalizationRegistry

登录后复制

在管理外部资源清理方面，提供了一个“最后一公里”的保障。这东西最核心的价值，就是它能让你在JavaScript对象被垃圾回收后，有机会去执行一些清理原生资源的操作。因为GC只管JS内存，管不了操作系统层面的文件句柄、网络套接字、数据库连接、或者WebAssembly分配的内存。

假设我们有一个Node.js应用，需要处理大量文件。我们可能会封装一个

FileHandle

登录后复制

类，它的实例内部持有操作系统分配的文件描述符。

const fs = require('fs');
const path = require('path');

// 注册一个 FinalizationRegistry 来处理文件句柄的关闭
const fileCleanupRegistry = new FinalizationRegistry((fd) => {
    console.log(`文件句柄 ${fd} 对应的JS对象被回收了，正在关闭文件句柄...`);
    fs.close(fd, (err) => {
        if (err) {
            console.error(`关闭文件句柄 ${fd} 失败:`, err);
        } else {
            console.log(`文件句柄 ${fd} 已成功关闭。`);
        }
    });
});

class ManagedFile {
    constructor(filePath) {
        this.filePath = filePath;
        this.fd = null; // 操作系统文件描述符

        // 模拟打开文件，获取文件描述符
        this.fd = fs.openSync(filePath, 'r');
        console.log(`文件 ${filePath} 已打开，句柄为 ${this.fd}`);

        // 将当前 ManagedFile 实例注册到清理注册表，关联文件句柄
        fileCleanupRegistry.register(this, this.fd);
    }

    read() {
        // 模拟读取文件内容
        console.log(`读取文件 ${this.filePath} (句柄: ${this.fd})...`);
        // 实际操作...
    }

    // 可以在这里提供一个显式关闭方法，但 FinalizationRegistry 是一个兜底
    close() {
        if (this.fd !== null) {
            fs.closeSync(this.fd);
            console.log(`文件 ${this.filePath} (句柄: ${this.fd}) 已显式关闭。`);
            this.fd = null;
            // 显式关闭后，不再需要 FinalizationRegistry 监控，可以取消注册
            // fileCleanupRegistry.unregister(this); // 如果需要，可以取消注册
        }
    }
}

// 使用 ManagedFile
function processSomeFiles() {
    const tempFile = path.join(__dirname, 'temp.txt');
    fs.writeFileSync(tempFile, "Hello FinalizationRegistry!");

    let file1 = new ManagedFile(tempFile);
    file1.read();

    // file1 现在被设置为 null，它指向的 ManagedFile 实例不再有强引用
    // 在某个不确定的时间点，GC会回收 file1 实例，
    // 进而触发 fileCleanupRegistry 的回调，关闭文件句柄。
    file1 = null;

    // 为了观察效果，我们等待一段时间，并希望GC能运行
    setTimeout(() => {
        console.log("等待GC清理文件句柄...");
        // 尝试删除文件，如果句柄没关，可能会失败
        try {
            fs.unlinkSync(tempFile);
            console.log("临时文件已删除。");
        } catch (e) {
            console.error("删除临时文件失败，可能句柄未关闭:", e.message);
        }
    }, 2000);
}

processSomeFiles();

登录后复制

在这个例子中，