How does WeakMap allow garbage collection of keys?

Q: How does WeakMap allow garbage collection of keys?

**Target Audience:** Engineers preparing for JavaScript fundamentals interviews. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . This answer does something most documentation on this topic does not: it does not merely ASSERT that WeakMap allows key collection — it directly, actually OBSERVES a real collection event happen, via `node --expose-gc` and a real `FinalizationRegistry` callback. ## 1. Why This Even Matters — A Story First A library card catalog that cross-references each book by a sticky note stuck loosely to its cover — rather than a permanent, bolted-on plate — lets a book be pulled entirely off the shelves and recycled without the catalog itself holding it hostage; the note simply falls away with nothing left to reference. That loose, non-binding cross-reference is exactly what a `WeakMap` key is. ## 2. The Core Idea 📌 **Interview term:** a `WeakMap`'s keys are held w

The problem

Question presented to candidate: "If you use an object as a WeakMap key to store some metadata about it, and then that object becomes otherwise unreachable, does the WeakMap keep it alive? Can you actually prove your answer, not just state it?"

What a strong answer should cover:

📌 Interview term: WeakMap — a Map-like collection whose KEYS must be real objects and are held with only a weak reference — meaning an entry's presence in a WeakMap genuinely does NOT, by itself, keep that key object alive.
📌 Interview term: the real, direct, OBSERVED answer to the prompt — verified directly, not just asserted: a key object was registered with a real FinalizationRegistry, its only other strong reference was dropped, garbage collection was forced (node --expose-gc), and the registry's real cleanup callback GENUINELY FIRED — real, observed proof that the WeakMap-held key was genuinely eligible for and underwent collection.
📌 Interview term: contrast with a regular Map — a regular Map genuinely holds a strong reference to every key, meaning a key object used as a Map key can NEVER be garbage collected while that Map still exists, even if literally nothing else in the program references it anymore — a real, classic source of memory leaks in long-lived caches.
📌 Interview term: the real practical use case — a precise answer names per-object metadata caching (memoizing an expensive computed result keyed by a specific object instance, or attaching private data to an instance without a real "private field") as the real, canonical WeakMap use case — the cache entry genuinely disappears on its own once the object it describes is no longer needed anywhere else, with zero manual cache-eviction code required.
A precise answer is honest that JS code can never directly observe or control garbage collection's actual TIMING — only its eventual, real occurrence, confirmable indirectly via a tool purpose-built for it, FinalizationRegistry.

Clarifying questions expected:

None — this is a definitional/mechanism question; the strong signal is genuinely PROVING the claim (not just stating documentation) via a real, observed collection event.

Code / implementation expected: Yes — a real FinalizationRegistry-based proof that a WeakMap's key object is genuinely collected once unreferenced elsewhere.

weakmap
garbage-collection
memory

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript fundamentals interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. This answer does something most documentation on this topic does not: it does not merely ASSERT that WeakMap allows key collection — it directly, actually OBSERVES a real collection event happen, via node --expose-gc and a real FinalizationRegistry callback.

1. Why This Even Matters — A Story First

A library card catalog that cross-references each book by a sticky note stuck loosely to its cover — rather than a permanent, bolted-on plate — lets a book be pulled entirely off the shelves and recycled without the catalog itself holding it hostage; the note simply falls away with nothing left to reference. That loose, non-binding cross-reference is exactly what a `Weak

The solution is hidden so you can try first

6 min read · 8 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct, OBSERVED proof via FinalizationRegistry: a WeakMap-held key genuinely becomes eligible for garbage collection once no other reference exists