How to prevent memory leaks in long-running Node.js services?

Memory management is critical for production stability. Here are key strategies: use process.memoryUsage() for monitoring, implement a restart policy with PM2 when heap usage exceeds thresholds, avoid global variables that accumulate data over time, prefer streams for large file processing instead of loading everything into memory, and always close database connections and event listeners in cleanup handlers.

The obvious answer is that you're probably holding onto references in a global scope or array and never clearing them, but I suppose reading the official docs on garbage collection behavior would be asking too much of this thread.

Real talk: run your service with --inspect, open chrome://inspect to

The most common leak sources in long-running Node processes:

1. Event listeners that are never removed (emitter.off()). A listener on a global emitter creates a root reference to its scope — if this happens inside an HTTP handler, you're leaking the entire request context every time the endpoint is called. Fix: always cleanup with res.on('close', () => emm.removeListener(...)).

2. Closures capturing large variables in long-lived objects (interval timers, promise chains that never resolve). The garbage collector can't free anything inside a scope held by an active reference. If you have setInterval(() => doSomething(largeObj), 100), and doSomething creates new closures repeatedly, memory grows linearly forever.

3. Cache objects with no eviction policy. A simple {} used as a cache will grow until OOM if there's no TTL or size limit. Use an LRU cache library (

The primary category of memory leak in Node.js environments originates from unclosed event emitters and listener accumulation — when you attach a '.on()' handler to a long-lived emitter (like 'process', or an EventEmitter instance that lives for the service's entire lifecycle) without ever calling removeListener, each invocation adds a function reference to an internal array of listeners, which prevents garbage collection. The worst offender is attaching anonymous functions in a loop: every iteration creates a new closure with its own scope capturing, and removing them becomes impossible because you lack the reference to the specific function instance. For production services I always enforce one of three patterns: either use removeListener explicitly in a 'cleanup' phase (though this is rare for long-running processes since they rarely have one), wrap listener creation in a named function so it can be removed by name, or — and this is my preferred approach for event emitters — use .once() when you only need to respond to the first occurrence.

The second category is cached collections that grow unbounded, which manifests as slow memory growth rather than a hard crash. This happens with user-specific caches (like request rate-limiters keyed by IP) that never evict old entries. The fix is always an LRU cache from the 'lru-cache' package or similar, with a configurable max size and TTL; do not roll your own because handling the eviction ordering correctly while maintaining O(1) access is deceptively complex when you account for edge cases like concurrent writes during cache pruning.

The third category is closures capturing large variables — this is the most subtle form of leak because it looks perfectly normal in code review. If you have a function that returns another function, and the inner one references any variable from the outer scope, that entire scope chain stays alive as long as the inner function exists. In HTTP handlers, passing a large buffer or object into a callback that gets stored for logging/retry purposes is a common source of this issue

Good point about EventEmitter listeners — I've seen that cause more issues than actual closures a few

Memory management in Node.js is fundamentally tied to V8's garbage collection strategy, which uses generational scavenging (young and old generations) with a write barrier mechanism that promotes objects from the nursery to the old space after they survive threshold collections. The most insidious source of memory leaks in long-running services isn't always obvious buffer accumulation — though uncapped array push operations are frequently cited as examples, I would argue the more pervasive category is retained closure scopes where an outer variable remains reachable through a callback registered on an event emitter or a promise chain that never resolves. This creates what we call a "detached reference" in GC parlance: the object isn't actively used by any business logic but cannot be collected because it still sits on some listener list.

To systematically identify these, you should leverage v8's built-in heap snapshot capabilities rather than relying on process RSS growth as your primary metric — RSS is a poor signal of actual leak because the OS can page out memory and V8 may not immediately return freed segments to the system due to its internal freelist pooling. The recommended workflow is: run node with --expose-gc, expose a diagnostic endpoint that invokes global.gc() after an intentional heap snapshot via v8.setHeapStatisticsCallback or by using the inspector module's heapSnapshot function. Comparing snapshots taken at T=0 and T=24h reveals objects surviving through collections — sort by retained size to identify the culprits quickly.

For common pattern-specific fixes: always remove event listeners on teardown with .off() calls, use WeakMap or WeakRef when you need a cache that doesn't prevent GC of its keys/values, and avoid creating closures inside loops that capture large scope variables — instead pass arguments explicitly to the callback function. If you are handling HTTP uploads, always pipe streams with backpressure logic (await stream.write() rather than fire-and-forget) because unconsumed buffers stay in V

Read the documentation first — I assume you have, but given this question exists here it's a fair assumption to make. If you haven't actually profiled your process with heap snapshots and are just guessing where memory is going, stop typing and do that instead. The most common culprits in Node

Heap dumps + heapdump2 for comparing snapshots is my go-to.