finalizationregistry用于在javascript对象被垃圾回收时执行清理外部资源的回调。其使用步骤为：1. 创建实例并传入回调函数，用于接收对象回收后的关联值并执行清理；2. 使用register方法注册目标对象及其关联值，可选提供解除注册令牌；3. 可通过unregister方法主动解除注册以防止回调触发。它适用于管理webassembly内存、文件句柄等非javascript自动管理的资源，但其回调是非确定性的，不能用于需立即执行的清理操作。与weakref不同，finalizationregistry关注对象生命周期终点而非是否持有引用，二者可协同实现缓存和资源清理。使用时应避免强引用导致内存泄漏、确保回调轻量，并将其作为兜底机制而非唯一清理手段。
JavaScript中的FinalizationRegistry提供了一种机制，允许你在一个对象被垃圾回收器回收时，执行一个回调函数。这并不是用来控制垃圾回收本身，而是为了在对象生命周期结束时，能够清理与其关联的外部资源，比如文件句柄、网络连接或WebAssembly内存等，这些资源可能不直接受JavaScript垃圾回收管理。它提供了一个观察点，让你知道某个JS对象已经“消失”了，可以进行后续的资源释放。
解决方案
FinalizationRegistry的核心思想是注册一个回调函数，并将其与你想要监控的对象关联起来。当这个对象被垃圾回收器判断为不再可达并即将被回收时，你注册的回调函数就会被调用。这个回调函数会收到一个你预先指定的“held value”，通常是用来标识或清理相关资源的凭证。
具体使用步骤如下：
立即学习“Java免费学习笔记（深入）”；
-
创建
FinalizationRegistry实例： 你需要创建一个FinalizationRegistry的新实例，并传入一个回调函数。这个回调函数会在注册的对象被回收时执行。const registry = new FinalizationRegistry((heldValue) => { // 当注册的对象被回收时，这里会执行 console.log(`对象已被回收，关联值是:`, heldValue); // 在这里执行清理操作，例如关闭文件句柄、释放WebAssembly内存等 if (typeof heldValue === 'string' && heldValue.startsWith('resource-')) { console.log(`清理资源: ${heldValue}`); // 实际的清理逻辑... } }); -
注册要监控的对象： 使用
registry.register(target, heldValue, unregisterToken)方法来注册一个对象。
-
target: 你想要监控的JavaScript对象。当这个对象被回收时，回调函数会触发。 -
heldValue: 一个任意值，当target被回收时，这个值会被作为参数传递给FinalizationRegistry的回调函数。这个值不能是target本身，否则会阻止target被回收。它通常是用来标识或帮助清理target关联的外部资源的。 -
unregisterToken(可选)：一个唯一的令牌。你可以使用这个令牌在target被回收前主动解除注册，防止回调被触发。
let myObject = {}; // 假设这是一个需要清理外部资源的对象 const resourceId = 'resource-12345'; // 外部资源的标识 registry.register(myObject, resourceId); // 假设myObject不再被引用，等待垃圾回收 myObject = null; // 解除对myObject的强引用 -
-
解除注册 (可选)： 如果你在注册时提供了
unregisterToken，并且在对象被回收前，你决定不再需要清理其关联资源，或者资源已经通过其他方式清理了，你可以使用registry.unregister(unregisterToken)来解除注册。let anotherObject = {}; const anotherResourceId = 'resource-67890'; const token = Symbol('unique-token-for-another-object'); // 使用Symbol作为唯一的unregisterToken registry.register(anotherObject, anotherResourceId, token); // 假设在某个时候，我们决定不需要等待GC来清理anotherObject的资源了 // 也许资源已经通过其他同步方式清理了 registry.unregister(token); anotherObject = null; // 解除强引用
需要强调的是，FinalizationRegistry的回调函数是非确定性的。它只会在对象被垃圾回收器实际回收时才执行，而JavaScript引擎何时运行垃圾回收是不可预测的。这意味着你不能依赖它来执行时间敏感或必须立即执行的清理操作。它更适合用于“尽力而为”的后台资源清理。
FinalizationRegistry与WeakRef有何不同，它们如何协同工作？
理解FinalizationRegistry，常常会把它和WeakRef（弱引用）拿来比较，因为它们都与JavaScript对象的生命周期和垃圾回收有关，但解决的问题却截然不同。我个人觉得，它们的区别就像是“观察”和“持有”的关系。
WeakRef，顾名思义，是创建一个对象的弱引用。这意味着如果你只通过WeakRef来引用一个对象，这个对象仍然可以被垃圾回收器回收。WeakRef的deref()方法可以让你尝试获取被引用的对象，但如果对象已经被回收，它会返回undefined。WeakRef的核心在于，它允许你“指向”一个对象，但又不妨碍它被回收。这对于构建缓存、实现某些观察者模式或者避免循环引用导致内存泄漏非常有用，它让你可以“窥视”一个对象是否还存在。
而FinalizationRegistry呢，它根本不关心你是否能“指向”那个对象，它只关心那个对象“什么时候消失了”。它的主要作用是，当一个对象真正被垃圾回收时，提供一个执行清理操作的钩子。它关注的是对象生命周期的终点，以及如何处理与该对象关联的外部资源。你可以把它看作是一个“讣告服务”，当某个对象“去世”了，它会通知你，然后你可以处理它的“遗物”。
它们两者虽然独立，但在某些场景下可以巧妙地协同工作。举个例子，假设你有一个大型数据对象的缓存，这个对象可能还关联着一些操作系统级别的文件句柄或网络连接。
- 你可以使用
WeakRef来在缓存中存储这些大型数据的弱引用。这样，当内存不足时，如果这些数据对象没有其他强引用，它们就可以被垃圾回收，从而释放内存。 - 同时，你可以用
FinalizationRegistry来注册这些大型数据对象。当某个数据对象被垃圾回收时，FinalizationRegistry的回调就会被触发，此时你可以在回调中安全地关闭之前打开的文件句柄或网络连接，清理那些JavaScript垃圾回收器无法直接管理的外部资源。
这种组合方式，既能让JavaScript对象在不再需要时被回收以节省内存，又能确保在它们被回收后，其对应的非JavaScript资源也能得到及时（尽管是非确定性）的清理。它提供了一种“柔性”的资源管理策略，尤其是在处理那些生命周期与JavaScript对象紧密绑定但又超出V8引擎管理范畴的资源时。
使用FinalizationRegistry时需要注意哪些潜在陷阱和最佳实践？
FinalizationRegistry虽然强大，但它并不是银弹，甚至可以说，如果用得不好，反而会引入新的问题。我个人在使用它时，最头疼的就是它的非确定性，以及由此带来的各种“意外”。
一个最显著的陷阱就是非确定性。正如前面提到的，你无法预测FinalizationRegistry的回调何时会执行。它可能在对象被解除引用后立即执行，也可能在程序运行了很长时间后才执行，甚至在程序退出前都可能不执行。这意味着你绝对不能依赖它来执行那些必须立即、同步完成的清理工作，比如在用户点击“保存”后立即关闭文件，或者在HTTP请求完成后立即释放网络连接。对于这类任务，显式的close()方法、try...finally块或async/await模式才是正确的选择。FinalizationRegistry更适合作为一种“尽力而为”的后台清理机制。
另一个常见的陷阱是意外地阻止对象被垃圾回收。FinalizationRegistry的回调函数以及你传递给register方法的heldValue，都必须非常小心，确保它们不会强引用你想要被回收的target对象，或者任何通过target可达的对象。如果回调函数形成了一个闭包，并且这个闭包捕获了target的强引用，那么target将永远不会被回收，FinalizationRegistry的回调也就永远不会触发。这本质上是制造了一个内存泄漏。我见过不少新手在这里犯错，以为把对象传给heldValue就能在回调里拿到它，结果反而阻止了GC。记住，heldValue只是一个标记，不应该是target本身。
此外，性能开销也是需要考虑的。虽然FinalizationRegistry本身被设计得相对高效，但如果你注册了大量的对象，并且每个回调都执行了复杂的逻辑，这无疑会增加垃圾回收器的负担，并可能导致应用程序的卡顿。回调函数应该尽可能地轻量和快速。
最佳实践：
-
限制使用场景：只在处理那些无法通过其他同步或确定性方式清理的外部资源时考虑使用
FinalizationRegistry。典型的例子是与JavaScript堆外内存（如WebAssembly内存、Node.js原生模块分配的内存）关联的资源。 -
回调函数要简洁：
FinalizationRegistry的回调函数应该尽可能地简单、快速，并且不执行任何可能阻塞事件循环的操作。它应该只包含释放外部资源的逻辑。 -
避免强引用：确保
heldValue和回调函数的闭包不会意外地持有对目标对象的强引用。heldValue通常应该是一个原始值（字符串、数字、Symbol）或者一个弱引用。 -
设计健壮的资源管理：不要把
FinalizationRegistry作为唯一的资源管理策略。对于关键资源，始终要有明确的生命周期管理和显式的清理方法。FinalizationRegistry可以作为一种补充或“兜底”机制，以防万一。 -
测试的挑战：由于其非确定性，测试涉及
FinalizationRegistry的代码会非常困难。你无法强制垃圾回收，所以很难在测试中可靠地验证回调是否被触发。在生产环境中，你可能需要依赖日志或监控来确认其效果。
总的来说，FinalizationRegistry是一个低级且功能强大的工具，它赋予了JavaScript与外部资源更精细的交互能力。但它要求开发者对垃圾回收机制有深入的理解，并能接受其非确定性带来的限制。
FinalizationRegistry在实际应用场景中能解决什么问题？
从我的经验来看，FinalizationRegistry在一些特定但非常重要的场景中能发挥作用，尤其是在JavaScript需要与“外部世界”打交道时。它不是一个日常开发中会频繁使用的API，但当遇到特定问题时，它往往是那个能“兜底”的解决方案。
一个典型的应用场景是管理WebAssembly（Wasm）模块分配的内存。当你在Wasm中分配了一块内存（例如使用C/C++的malloc），并将其传递给JavaScript，JavaScript只是持有一个指向这块内存的视图（比如一个ArrayBuffer）。当这个ArrayBuffer在JavaScript中被垃圾回收时，Wasm内部分配的内存并不会自动释放。这时，你可以用FinalizationRegistry来监听这个ArrayBuffer对象的回收事件，并在回调中调用Wasm的内存释放函数（比如free），从而确保Wasm内存得到清理。这对于避免内存泄漏，尤其是在处理大型数据或频繁创建/销毁Wasm实例的场景中，至关重要。
类似的，在Node.js环境中，如果你的原生C++插件（Native Addons）分配了堆外内存或其他操作系统资源（如文件描述符、网络套接字句柄），并且这些资源与JavaScript对象（例如一个代表文件句柄的JS对象）的生命周期绑定。当这个JavaScript对象被垃圾回收时，你可以通过FinalizationRegistry来触发C++侧的资源释放函数。这确保了跨语言边界的资源管理能够得到妥善处理，避免了操作系统资源泄漏。
此外，它也可以用于一些高级缓存策略。想象一个图片缓存，你不仅缓存了图片的JavaScript对象，还可能在后台为这些图片预加载了一些GPU纹理或解码后的像素数据。当JavaScript的图片对象不再被引用而即将被回收时，你可以使用FinalizationRegistry来清理那些与GPU或操作系统相关的资源。这使得缓存的淘汰机制更加完善，因为除了JavaScript内存，它还能管理到那些更“底层”的资源。
我个人觉得，FinalizationRegistry最核心的价值在于它提供了一个“异步的、尽力而为的资源清理机制”。它认识到JavaScript的垃圾回收是自动的、不可控的，但又提供了一个机会，让开发者可以在这个自动过程中插入自己的清理逻辑。它不是用来替代显式资源管理（比如fetch().then(() => cleanup())），而是用来处理那些“我无法确定何时不再需要，但一旦不再需要就应该清理”的场景。它填补了JavaScript在与外部复杂系统交互时，资源生命周期管理的一个空白，尤其是在那些无法通过同步、确定性手段来保证资源释放的边界情况下。
