Garbage Collection & Memory Leaks

The plain-language idea

JavaScript doesn't ask "is this variable out of scope" — it asks "can this object still be reached, starting from something the program can directly access (globals, the current call stack)?" If yes, it's kept. If no, the garbage collector reclaims it. A "memory leak" in JS isn't a low-level bug like in C — it's always an object staying reachable when you didn't intend it to be.

function attachListener() {
  const hugeData = new Array(1_000_000).fill("x");
  document.getElementById("btn").addEventListener("click", () => {
    console.log(hugeData.length);   // this closure keeps hugeData reachable
  });
}

As long as that click listener is attached, hugeData stays reachable through the closure — even though attachListener itself finished running long ago. Remove the listener (or the element), and hugeData becomes reclaimable.

The GC asks one question about every object: can it still be reached from a root — globals, the call stack?

BackNext

The classic leak sources

Watch out

• Forgotten event listeners. A listener attached to a long-lived object (like window) but never removed keeps everything its callback closes over reachable forever — this is the single most common real-world JS leak.
• Closures holding more than they need. A closure captures the whole enclosing scope's live variables, not just the ones it uses — a large unused variable sitting in the same scope as one you do need stays reachable too.
• Growing caches with no eviction. A Map used as a cache that only ever adds entries, never removes old ones, will grow indefinitely — this is exactly the problem WeakMap (previous lesson) solves when the key is an object.
• Detached DOM nodes. Removing an element from the page doesn't free it if a JS variable (or a closure) still references it — it becomes a "detached" node: invisible, but still in memory.

Why this matters in interviews

"Find the memory leak in this code" is a real, common exercise — recognizing forgotten listeners and over-capturing closures as reachability problems (not vague "bad code") is what separates a correct diagnosis from a guess.