Tracking Down a Slow Memory Leak in Node or Go, Step by Step

Memory usage that climbs and then plateaus at a stable, higher level is often normal, reflecting caches warming up or connection pools filling to their configured size. A real leak keeps climbing indefinitely, with no plateau, over a period of hours or days. Graph memory usage over a long enough window to distinguish the two before spending time chasing something that might just be expected behavior.

A single heap snapshot tells you what's currently allocated, but not what's actually growing. Take two or more snapshots spaced well apart, under representative load, and compare them: the growing leak shows up as the object type or allocation site whose count or size increased the most between snapshots, standing out clearly against everything that stayed roughly flat.

Finding what's growing is only half the answer. The other half is finding what's still holding a reference to it, preventing it from ever being freed, such as an array or map that things get added to but never removed from, or an event listener that's registered repeatedly without ever being cleaned up. Most heap profiling tools can show you the retaining path directly, which turns this from a guessing exercise into a straightforward trace back through the code.

Certain patterns cause a disproportionate share of real leaks in both Node and Go: an event listener attached inside a function that runs repeatedly without ever being removed, a cache with no eviction policy that grows without bound, a goroutine in Go that blocks forever waiting on a channel nobody writes to again, or a closure that unintentionally captures and retains a large object. Checking these patterns first often finds the leak faster than a fully generic profiling pass.

After applying a fix, don't assume it worked. Rerun the same two-snapshot comparison from step two under the same representative load and confirm the previously growing allocation has actually stopped growing. A leak that seems fixed based on code review alone can still be present if the actual retaining reference wasn't the one that got removed, and the snapshot comparison is what proves the fix worked rather than just looking plausible.

The whole sequence, in short:

1. Graph memory over hours or days to confirm it climbs without plateauing, rather than settling at a stable, higher level after cache warm-up.
2. Take two or more heap snapshots well apart under representative load, and compare them to see which allocation grew the most.
3. Trace the growing allocation back to the retaining reference, such as a collection nothing is removed from or a listener never cleaned up.
4. Check the usual suspects first: repeated listeners, caches with no eviction, goroutines blocked forever, and closures that retain large objects.
5. Apply the fix, then rerun the same snapshot comparison under the same load and confirm the growth has actually stopped.

Say a Node service sets up a fresh event listener on a shared emitter every time a particular request handler runs, intending it to be short-lived, but never explicitly removes it once that request finishes. Under steady traffic, listeners accumulate on that emitter indefinitely, each one holding onto whatever it captured in its closure, and memory climbs in a pattern that looks, on a graph, exactly like the slow, steady leak described above. A heap snapshot comparison points directly at the growing listener count on that one emitter, and the fix is a single explicit removal call the original code was missing, not a rewrite of anything else.

Say a Go service spawns a goroutine per incoming request to wait on a result from a channel, but a code path exists where nothing ever writes to that channel under a specific error condition. That goroutine blocks forever, and its own stack and any variables it's holding onto never get freed, since the goroutine itself never actually exits. Enough requests hitting that error condition over time produces a slow, steady memory increase that traces back not to a data structure growing, but to leaked goroutines accumulating one at a time, each one small but permanent.