WeakRef和FinalizationRegistry提供弱引用与对象回收后回调机制，解决内存泄漏问题。WeakRef允许引用对象而不阻止其被垃圾回收，适用于缓存等场景避免内存泄漏；FinalizationRegistry在对象被回收后执行清理操作，用于释放文件句柄、数据库连接等外部资源。两者结合实现更精细的内存与资源管理，提升JavaScript在复杂应用中的性能与可靠性。
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
提供了一个相对优雅的机制，让我们可以“订阅”对象的回收事件，然后在回调中执行这些外部资源的清理工作。这比我们自己去维护一个复杂的生命周期管理系统要省心得多，虽然它的非确定性确实需要我们仔细考量其适用场景。
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();
在这个例子中，
ManagedFile
实例创建时，我们不仅打开了文件，还把这个实例和对应的文件描述符（
fd
）一起注册到了
fileCleanupRegistry
。当
file1
变量被设置为
null
，并且没有其他地方强引用
ManagedFile
实例时，GC最终会回收这个实例。一旦实例被回收，
fileCleanupRegistry
就会触发回调，传入我们注册时给定的
fd
，然后我们就可以安全地调用
fs.close()
来关闭文件句柄。
需要强调的是，
FinalizationRegistry
的回调是异步且非确定性的。你不能依赖它来执行那些必须立即完成的清理工作，比如事务提交前的锁释放。对于这类高优先级、高实时性要求的资源，你仍然需要显式地调用
close()
或
dispose()
方法。
FinalizationRegistry
更多的是作为一种兜底机制，防止开发者忘记显式清理时造成的资源泄漏。它确保了即使在最糟糕的情况下，外部资源最终也能被释放，而不是永远挂在那里。这种设计理念，其实是平衡了JS语言的便利性和底层资源管理的严谨性。
javascript java js 前端 node.js json node 操作系统 回调函数 工具 注册表 JavaScript 前端框架 NULL 封装 Token 回调函数 map JS undefined 对象 事件 dom 异步 数据库 ui webgl