You replace a leaking Map-based cache with a WeakMap keyed by the objects being cached. In which situations does the memory still not get released?

## What swapping to WeakMap actually changes A `Map` cache leaks for one reason: the map holds a strong reference to every key, so nothing you ever cached can be collected while the map is alive. Switching to `WeakMap` removes that one edge from the object graph. It removes nothing else. An object is collectable when *no* path from a root reaches it, so the swap helps only if the map's reference was the last one. That framing is the answer to the whole question, and everything below is a case of it. ## Case 1 — the key itself is long-lived ```js const cache = new WeakMap(); function compile(config) { if (!cache.has(config)) cache.set(config, buildExpensiveThing(config)); return cache.get(config); } ``` If `config` is a module-level singleton created once at startup, its entry lives as long as the module does. Nothing is wrong with the code; the weakness simply has no work to do. Weak keying only pays when keys have shorter lifetimes than the map. Cache against per-request or per-instance objects and it works; cache against long-lived roots and you have written a `Map` with fewer features. ## Case 2 — a second strong reference elsewhere This is the one that survives code review and shows up in a heap snapshot weeks later: ```js const cache = new WeakMap(); const seenForDebug = []; // <- strong, forever function handle(req) { seenForDebug.push(req); // pins every request cache.set(req, render(req)); } ``` The array keeps every `req` reachable, so every cache entry stays too. The same happens with a listener registered on a long-lived emitter and never removed, a closure captured by a still-pending promise or an uncancelled timer, or a diagnostics `Map` added "temporarily". The diagnosis is always the same: take a heap snapshot and look at the retaining path of one of the keys — the retainer will be the strong holder, never the WeakMap. ## Case 3 — values that reference other keys Weak maps are specified with ephemeron semantics. The value is reachable *through* the key, so this self-reference is safe: ```js const wm = new WeakMap(); let node = {}; wm.set(node, { owner: node }); // value points back at its own key node = null; // entry is still collectable ``` The specification requires that a key is not treated as live merely because some value refers to it, so this cycle does not leak — engines resolve weak-map liveness iteratively rather than in one pass. What does leak is a value pointing at a *different* key of the same map: ```js wm.set(a, { next: b }); // while `a` is live, `b`'s entry is retained ``` While `a` is reachable, `wm.get(a)` must return a value that references `b`, so `b` stays reachable and `b`'s own entry stays too. Build a chain like this over a graph and one live root retains the entire structure. If you need to model relationships between keys, store identifiers or use a structure whose lifetimes you manage explicitly. ## Case 4 — the keys are primitives Most real caches are keyed by a URL, a SQL string, a request id, or a numeric id. `WeakMap` rejects all of them with a `TypeError`, and no wrapper fixes it: boxing the string into a fresh `new String(url)` produces a new object each call, so lookups never hit. Primitives have no identity the collector can track. For those caches you need a strong `Map` and a real eviction policy — a maximum size with LRU replacement, a TTL sweep, or deletion tied to a lifecycle event such as request completion. "Use a WeakMap" is not an eviction policy, and treating it as one is the single most common misuse. ## Case 5 — the value is the heavy part Even when the keys behave, weakness protects only the key's lifetime, not the value's size. A cache whose values are megabyte buffers holds those buffers for as long as their keys live, which may be much longer than the value is useful. Weak keying and value-size bounding are separate problems, and only the first is solved for you. ## How to diagnose it in practice When memory still grows after the swap, do not reason about the collector — measure. Take two heap snapshots under load, compare the retained sizes, pick a key object that should have gone, and read its retaining path. Either something strong appears in that path (cases 1, 2, 3), or the keys turn out never to have been objects at all (case 4). The answer to "why did WeakMap not fix my leak" is essentially always "because something else was still holding the key". ## What to say in the interview Lead with the principle — WeakMap drops one reference, and collection needs *all* references gone — then name the concrete cases. Adding that primitives cannot be keys, and that the fallback is a bounded `Map`, is what separates an answer that has been used in production from one that has been read about.