Come rilevi e correggi le memory leak in Node.js?

Question

Accepted Answer

Una **memory leak** è memoria che non è più necessaria ma non viene mai liberata, perché qualcosa la referenzia ancora. Nel tempo l'heap del processo cresce finché non rallenta o si blocca (out-of-memory). Nei server Node di lunga durata, le leak sono un problema serio in produzione.

## Sorgenti comuni di leak

```js
// 1. Unbounded caches / global collections that only grow
const cache = new Map();
app.get("/:id", (req, res) => { cache.set(req.params.id, data); }); // never cleared → grows forever

// 2. Forgotten event listeners (added repeatedly, never removed)
emitter.on("data", handler); // if added per-request and never removed → accumulates

// 3. Forgotten timers
setInterval(() => {...}, 1000); // never cleared, holds references alive

// 4. Closures capturing large objects longer than needed
function outer() {
  const huge = loadBigData();
  return () => huge.length; // keeps `huge` alive as long as the closure lives
}
```

Il filo conduttore: un riferimento raggiungibile (una Map globale, un listener attivo, un timer in esecuzione, una closure) impedisce agli oggetti di essere garbage-collected anche se non sono più utili.

## Rilevamento di leak

```js
// 1. Watch heap growth over time — steady upward trend = likely leak
setInterval(() => {
  const { heapUsed } = process.memoryUsage();
  console.log(`heap: ${(heapUsed / 1e6).toFixed(1)} MB`);
}, 10000);
```

```bash
# 2. Heap snapshots — capture at two points, compare what grew
node --inspect app.js     # then use Chrome DevTools → Memory → heap snapshots
# or the heapdump / clinic.js tools
```

Il processo diagnostico: conferma che l'heap cresca costantemente (non solo fluttuazione normale), quindi prendi **heap snapshots** prima/dopo un workload e confronta per trovare quali tipi di oggetti si accumulano ("retained size" crescente).

## Correzione di leak

```js
// ✅ bound caches with TTL/size limits (LRU)
import { LRUCache } from "lru-cache";
const cache = new LRUCache({ max: 1000, ttl: 1000 * 60 }); // evicts automatically

// ✅ always remove listeners and clear timers
emitter.off("data", handler);
clearInterval(timer);

// ✅ use WeakMap/WeakSet for metadata that shouldn't keep objects alive
const meta = new WeakMap(); // entries are GC'd when the key object is
```

Le correzioni rispecchiano le cause: cache limitate (LRU con dimensione max/TTL), abbina sempre creazione di listener/timer con cleanup, e usa `WeakMap`/`WeakSet` per metadati keyed su oggetti che non dovrebbero bloccare gli oggetti in memoria.

## Perché è importante

Le memory leak sono particolarmente pericolose in Node perché i server sono **long-running** — una leak lenta che è invisibile nello sviluppo degrada gradualmente e alla fine blocca un processo in produzione (spesso riavviandosi e perdendo il lavoro in volo).

Conoscere le sorgenti classiche (cache illimitate, listener/timer non rimossi, closure persistenti), come rilevarle (monitoraggio dell'heap + confronto snapshot con DevTools/clinic.js), e le correzioni (cache LRU limitate, cleanup disciplinato, `WeakMap`) è essenziale per gestire servizi Node affidabili e stabili nel tempo.