1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
---
title: FinalizationRegistry
slug: Web/JavaScript/Reference/Global_Objects/FinalizationRegistry
tags:
- FinalizationRegistry
- GC
- 垃圾回收
translation_of: Web/JavaScript/Reference/Global_Objects/FinalizationRegistry
---
<div>{{JSRef}}</div>
<p><strong><code>FinalizationRegistry</code> 对象可以让你在对象被垃圾回收时请求一个回调。</strong></p>
<h2 id="描述">描述</h2>
<p><code>FinalizationRegistry</code> 提供了这样的一种方法：当一个在注册表中注册的对象被回收时，请求在某个时间点上调用一个清理回调。（清理回调有时被称为 finalizer ）。</p>
<div class="note">
<p><strong>注意：</strong> 清理回调不应被用于必要的程序逻辑。详情请看<a href="#Notes_on_cleanup_callbacks">清理回调的注意事项</a>。</p>
</div>
<p>你在回调中创建了如下的 registry：</p>
<pre class="brush: js">const registry = new FinalizationRegistry(heldValue => {
// ....
});
</pre>
<p>然后，你可以通过调用`register`方法，注册任何你想要清理回调的对象，传入该对象和*所含的值*。</p>
<pre class="brush: js">registry.register(theObject, "some value");
</pre>
<p>The registry does not keep a strong reference to the object, as that would defeat the purpose (if the registry held it strongly, the object would never be reclaimed).</p>
<p>If <code>theObject</code> is reclaimed, your cleanup callback may be called at some point with the <em>held value</em> you provided for it (<code>"some value"</code> in the above). The held value can be any value you like: a primitive or an object, even <code>undefined</code>. If the held value is an object, the registry keeps a <em>strong</em> reference to it (so it can pass it to your cleanup callback later).</p>
<p>If you might want to unregister an object later, you pass a third value, which is the <em>unregistration token</em> you'll use later when calling the registry's <code>unregister</code> function to unregister the object. The registry only keeps a weak reference to the unregister token.</p>
<p>It's common to use the object itself as the unregister token, which is just fine:</p>
<pre class="brush: js">registry.register(theObject, "some value", theObject);
// ...some time later, if you don't care about `theObject` anymore...
registry.unregister(theObject);
</pre>
<p>It doesn't have to be the same object, though; it can be a different one:</p>
<pre class="brush: js">registry.register(theObject, "some value", tokenObject);
// ...some time later, if you don't care about `theObject` anymore...
registry.unregister(tokenObject);
</pre>
<h2 id="Constructor">Constructor</h2>
<dl>
<dt>{{jsxref("FinalizationRegistry/FinalizationRegistry", "FinalizationRegistry()")}}</dt>
<dd>Creates a new <code>FinalizationRegistry</code> object.</dd>
</dl>
<h2 id="Instance_methods">Instance methods</h2>
<dl>
<dt>{{jsxref("FinalizationRegistry.register", "FinalizationRegistry.prototype.register()")}}</dt>
<dd>Registers an object with the registry in order to get a cleanup callback when/if the object is garbage-collected.</dd>
<dt>{{jsxref("FinalizationRegistry.unregister", "FinalizationRegistry.prototype.unregister()")}}</dt>
<dd>Unregisters an object from the registry.</dd>
</dl>
<h2 id="Avoid_where_possible">Avoid where possible</h2>
<p>Correct use of <code>FinalizationRegistry</code> takes careful thought, and it's best avoided if possible. It's also important to avoid relying on any specific behaviors not guaranteed by the specification. When, how, and whether garbage collection occurs is down to the implementation of any given JavaScript engine. Any behavior you observe in one engine may be different in another engine, in another version of the same engine, or even in a slightly different situation with the same version of the same engine. Garbage collection is a hard problem that JavaScript engine implementers are constantly refining and improving their solutions to.</p>
<p>Here are some specific points that the authors of the WeakRef proposal that FinalizationRegistry is part of included in its <a href="https://github.com/tc39/proposal-FinalizationRegistrys/blob/master/README.md">explainer document</a>:</p>
<blockquote>
<p><a href="https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)">Garbage collectors</a> are complicated. If an application or library depends on GC cleaning up a FinalizationRegistry or calling a finalizer [cleanup callback] in a timely, predictable manner, it's likely to be disappointed: the cleanup may happen much later than expected, or not at all. Sources of variability include:</p>
<ul>
<li>One object might be garbage-collected much sooner than another object, even if they become unreachable at the same time, e.g., due to generational collection.</li>
<li>Garbage collection work can be split up over time using incremental and concurrent techniques.</li>
<li>Various runtime heuristics can be used to balance memory usage, responsiveness.</li>
<li>The JavaScript engine may hold references to things which look like they are unreachable (e.g., in closures, or inline caches).</li>
<li>Different JavaScript engines may do these things differently, or the same engine may change its algorithms across versions.</li>
<li>Complex factors may lead to objects being held alive for unexpected amounts of time, such as use with certain APIs.</li>
</ul>
</blockquote>
<h2 id="Notes_on_cleanup_callbacks">Notes on cleanup callbacks</h2>
<p>Some notes on cleanup callbacks:</p>
<ul>
<li>Developers shouldn't rely on cleanup callbacks for essential program logic. Cleanup callbacks may be useful for reducing memory usage across the course of a program, but are unlikely to be useful otherwise.</li>
<li>A conforming JavaScript implementation, even one that does garbage collection, is not required to call cleanup callbacks. When and whether it does so is entirely down to the implementation of the JavaScript engine. When a registered object is reclaimed, any cleanup callbacks for it may be called then, or some time later, or not at all.</li>
<li>It's likely that major implementations will call cleanup callbacks at some point during execution, but those calls may be substantially after the related object was reclaimed.</li>
<li>There are also situations where even implementations that normally call cleanup callbacks are unlikely to call them:
<ul>
<li>When the JavaScript program shuts down entirely (for instance, closing a tab in a browser).</li>
<li>When the <code>FinalizationRegistry</code> instance itself is no longer reachable by JavaScript code.</li>
</ul>
</li>
</ul>
<h2 id="Examples">Examples</h2>
<h3 id="Creating_a_new_registry">Creating a new registry</h3>
<p>You create the registry passing in the callback:</p>
<pre class="brush: js">const registry = new FinalizationRegistry(heldValue => {
// ....
});
</pre>
<h3 id="Registering_objects_for_cleanup">Registering objects for cleanup</h3>
<p>Then you register any objects you want a cleanup callback for by calling the `register` method, passing in the object and a *held value* for it:</p>
<pre class="brush: js">registry.register(theObject, "some value");</pre>
<h2 id="Specifications">Specifications</h2>
<table class="standard-table">
<thead>
<tr>
<th scope="col">Specification</th>
</tr>
</thead>
<tbody>
<tr>
<td>{{SpecName('WeakRefs', '#sec-finalization-registry-objects', 'FinalizationRegistry')}}</td>
</tr>
</tbody>
</table>
<h2 id="Browser_compatibility">Browser compatibility</h2>
<p>{{Compat("javascript.builtins.FinalizationRegistry")}}</p>
<h2 id="See_also">See also</h2>
<ul>
<li>{{jsxref("WeakRef")}}</li>
<li>{{jsxref("WeakSet")}}</li>
<li>{{jsxref("WeakMap")}}</li>
</ul>
<div id="gtx-trans" style="position: absolute; left: 224px; top: 147px;">
<div class="gtx-trans-icon"></div>
</div>
|
