Garbage Collection Isn't Magic: Why Your App Still Leaks Memory

You picked JavaScript (or Python, or Go, or Java) partly so you'd never have to think about memory. No malloc, no free, no dangling pointers. The runtime cleans up after you.

So why does your app get slower the longer it runs? Why does the process climb from 80 MB to 1.5 GB overnight, then feel instant again the moment you restart, only to climb right back up?

Here is the uncomfortable truth: the garbage collector is working perfectly. It is reclaiming exactly what it was designed to reclaim. The leak is not a failure of the language. It is a data structure you wrote that holds a reference forever.

In this post I'll show how reachability actually works, why two styles of collector differ, and the one-line mental model that stops the most common memory leak in modern code. There's a working example at the end. ([I wrote more on profiling this here][add link].)

Garbage collection decides one question: is it reachable?

Modern collectors do not count how many times you use a value. They ask a single, sharp question: can I still get to this object from somewhere that matters?

The "somewhere that matters" set is called the roots. Roots are the live, in-scope things: local variables on the call stack, globals, event handlers the runtime still tracks. From those roots, the collector walks every reference, then every reference those references hold, and so on, marking everything it touches as alive. Everything it never reaches is garbage, and it gets freed in bulk.

That is the whole model. If you can draw a line of pointers from a root to your object, the object survives. If you can't, it dies.

This is beautiful and generous, and it has one sharp edge it never warns you about: the collector has no opinions about your data structures. If your cache holds a pointer to a task you looked at an hour ago, the collector traces that pointer, reaches the task, and concludes "alive." It is not leaking. It is obeying you.

Reachability is not reference counting

People often picture garbage collection as a tally: every object counts how many things point at it, and when the count hits zero, free it on the spot. That strategy is real, it's called reference counting, and some languages use it (Python's CPython is the famous example, with a tracing collector as backup).

It has one fatal flaw: cycles.

a = {}
b = {}
a["partner"] = b
b["partner"] = a
# a and b now reference each other.
# Each has a reference count of at least 1, forever,
# even if nothing else in the program can reach them.

Two objects pointing at each other never hit zero. A pure reference counter would hold them until the process exits.

The collectors in JavaScript, Go, and Java don't have this problem, because they don't count references at all. They trace from roots, periodically, and anything unreachable dies regardless of how many internal pointers it has. Cycles are free.

Which means: if you are debugging a memory leak in a tracing-collected language, the cycle explanation is a dead end. The real cause is almost always simpler.

The modern leak, with a real example

A reader was sketching a "recently viewed" menu for a task app. Clean, tiny feature. This was the heart of it:

const recent = [];

function trackView(task) {
  recent.push(task); // every task we ever look at lands here
  renderRecent(recent);
}

It felt great for the first fifty views. Then the UI slowed. Then it crawled. Restart, instant again, fifty more views, slow again.

Nothing is wrong with that push. Nothing is wrong with the language. The problem is that recent is a root-reachable array, and it holds a pointer to every task the user has ever opened. The collector traces the chain recent -> task, marks each task alive, and correctly refuses to free it. The array grows without bound. So does memory.

The fix is not smarter collection. It is to stop holding the reference:

const RECENT_LIMIT = 20;
const recent = [];

function trackView(task) {
  recent.push(task);
  if (recent.length > RECENT_LIMIT) {
    recent.shift(); // drop the oldest entry
    // nothing else points to it now -> unreachable -> collected
  }
  renderRecent(recent);
}

The moment shift() removes the last reference to an old task, the collector can no longer reach it from any root. Next collection cycle, that memory comes back. No free(), no delete. Just a data structure that finally agrees to let go.

A mental model that catches these before they ship

After the tenth leak of this shape, I wrote myself a one-line rule and taped it to the mental wall:

If a collection can grow without bound, treat it as a leak until proven otherwise.

When you review a PR, scan for these patterns:

Caches and "recent" lists with no eviction policy or size cap.
Event listeners or observers added but never removed, holding their context alive.
Closures that capture large objects they never actually need.
Global accumulators (logs, metrics, registries) that append forever.
Maps keyed by long-lived objects where stale keys are never deleted.

Each of these is a root-reachable structure quietly pinning memory in place. The collector is doing its job. The structure is doing yours, badly.

The takeaway

Automatic memory management is not automatic memory forgetting. The collector will reclaim everything you stop reaching for, and it will dutifully keep everything you keep reaching for, even if you forgot you still were.

So the next time your app slows and stays slow, before you blame the runtime, ask the only question that matters: what am I still pointing at?

I write about performance and clean architecture every week. Follow along if that's your kind of thing.

Over to you: what's the dumbest memory leak you've ever shipped, and how long did it take you to find it? Drop it below, I'm collecting war stories. 👇

推荐订阅源