WeakMap・WeakRef・FinalizationRegistryと弱参照の意味論

なぜ弱参照を学ぶのか

JavaScriptのGCは「もう使わないオブジェクト」ではなく、どこからも辿れなくなった到達不能なオブジェクトだけを回収します。詳しくは ガベージコレクションのブラウザ内動作 で扱いましたが、ここに実務上のジレンマがあります。「あるオブジェクトに付随情報を結び付けたい。ただしそのオブジェクトの寿命までは延ばしたくない」というケースです。通常の参照（強参照）でMapに入れればキーは決して消えず、リークします。これを解くのが弱参照であり、WeakMap・WeakSet・WeakRef・FinalizationRegistryの4つです。本稿はこれらの意味論を、GCの到達可能性という一点から正確に解きほぐします。前提となる値とオブジェクトの扱いは JavaScript を参照してください。

強参照と弱参照：到達可能性への寄与の差

参照には2種類あります。**強参照（strong reference）**は、そこから辿れる対象を生存扱いにします。GCルート（グローバル、実行スタック上の変数など）から強参照だけでオブジェクトに辿り着けるなら、それは到達可能＝回収されません。

弱参照（weak reference）は、対象を指してはいるが到達可能性の判定に寄与しない参照です。あるオブジェクトへの参照が弱参照しか残っていない状態を「弱到達可能（weakly reachable）」と呼びます。GCはこのオブジェクトを「実質ゴミ」とみなし、いつでも回収できます。

WeakMap：キーを弱く持つ連想配列

WeakMapは、キーへの参照を弱参照で保持するMap類似のコレクションです。Mapとの差は到達可能性のモデルにあります。

通常のMapに要素をキーとして入れると、Mapがキーを強参照するため、その要素はDOMから外してもMap経由で到達可能なまま残りリークします。WeakMapではキーが弱く保持されるので、キーが他のどこからも強参照されなくなった瞬間、そのキーは弱到達可能になり、GCがキーごとエントリ（値も含む）を回収します。手動のdeleteなしに掃除が進むのが本質です。

const meta = new WeakMap();
function attach(el) {
  // el を生かさずに付随情報を結び付ける
  meta.set(el, { createdAt: Date.now() });
}
// el が他から参照されなくなれば、meta 内のエントリも自動で消える

なぜ列挙できないのか

WeakMapにkeys()やsizeが無いのは設計上の制約ではなく、意味論的に成立しないからです。エントリが生きているかはGCのタイミングに依存します。もし列挙できれば、「いつ消えるか」がGCの実行タイミングという観測不能・非決定的な事象を通じてプログラムから見えてしまい、GCの挙動が言語仕様の観測可能な振る舞いに漏れ出します。列挙手段を持たないことで、「弱到達可能になったキーはユーザコードから二度と取り出せない」を保証し、回収タイミングを完全にエンジン任せにできます。WeakSetも同じ理屈で、値を弱く持ち列挙できません。

WeakRef：個別オブジェクトへの弱い参照

WeakMapがコレクションなのに対し、WeakRefは単一オブジェクトへの弱参照を明示的に作るプリミティブです。new WeakRef(obj)で生成し、ref.deref()で対象を取り出します。

const ref = new WeakRef(bigObject);
// 後で取り出す
const obj = ref.deref();
if (obj !== undefined) {
  use(obj);          // まだ生存していた
} else {
  // 既に回収済み。再取得や再生成が必要
}

deref()は、対象がまだ生存していればそのオブジェクトを、既に回収されていればundefinedを返します。注意すべきは到達可能性への影響です。deref()がオブジェクトを返した瞬間、その戻り値は強参照になります。つまり、現在のマイクロタスク（より正確には現在の同期実行の最後まで）の間はそのオブジェクトの回収が妨げられます。これは「derefで取れたのに次の行で消えていた」という不整合を防ぐための仕様で、同一ターン内ではderefの結果が一貫することが保証されます。

FinalizationRegistry：回収を“通知”する

FinalizationRegistryは、登録したオブジェクトが回収された後にコールバック（ファイナライザ）を呼んでもらう仕組みです。回収そのものではなく、回収の事後通知を受け取り、関連する外部リソース（キャッシュエントリ、開いたハンドルなど）を片付ける用途を想定します。

const registry = new FinalizationRegistry((heldValue) => {
  // target が回収された後に呼ばれ得る。heldValue で対象を識別
  cleanup(heldValue);
});
registry.register(target, "target-id-123");

registerの第1引数が監視対象、第2引数（held value）はコールバックに渡される識別子です。ここで決定的に重要なのは、held valueに対象自身を渡してはいけないことです。コールバックに渡すために対象を強参照すると、対象が永遠に到達可能になり、そもそも回収されずコールバックも呼ばれません。

ファイナライザの非決定性：最大の落とし穴

WeakRefとFinalizationRegistryは強力ですが、その実行タイミングは非決定的で、仕様上ほとんど何も保証されません。これを理解せずに使うと壊れます。

非決定性の根は単純で、これらの観測がすべてGCの内部都合に依存する点にあります。エンジンはインクリメンタルや並行回収（JavaScriptエンジンの内部 で触れたV8など）でGCを分割実行するため、「いつ回収したか」は外から予測できません。仕様もあえて緩く定め、実装が最適なGC戦略を選べる余地を残しています。

使い分けの指針

実務では迷ったらまずWeakMapです。多くの「対象を生かさずに付随データを持ちたい」要求はこれで解決し、列挙不能という制約も「掃除を完全自動化する代償」として理にかなっています。WeakRefとFinalizationRegistryは、画像やパース結果の弱いキャッシュ、外部リソースの漏れ検出など、非決定性を許容できる限られた場面でのみ使います。

まとめ