Kif tiskopri u tirreparti memory leaks f'Node.js?

Question

Accepted Answer

A **memory leak** hu memorja li m'għadix meħtieġa iżda qatt ma ġiet liberata, għaliex xi ħaġa għadha tirreferixxiha. Bit-temp il-heap tal-proċess jikber sakil-marħa jibbaġgħa jew jaħraq (out-of-memory). F'servers Node li jduru għal ħin twil, il-leaks huma ħtigħ ta' produzzjoni serja.

## Sorsi ta' leaks komuni

```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
}
```

It-tema komuni: referenza li tista' tissaħħa (Map globali, listener ħaj, timer mexxi, closure) iwaqqfu l-oġġetti milli jkunu garbage-collected anke meta m'għadhomx utli.

## Iskoperta ta' leaks

```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-proċess ta' dijanjostika: ikkonferma li l-heap jikber b'mod kostanti (mhux fluttwazzjoni normali biss), imbagħad ħu **heap snapshots** qabel/wara workload u qabbel biex issib liema tipi ta' oġġett jakkumulaw ("retained size" jikber).

## Tirreparti ta' leaks

```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
```
"}}
Li jiġu mir-raġuniet: caches limitati (LRU b'daqs/TTL massimu), dejjem ikkupja listener/timer creation ma' cleanup, u uża `WeakMap`/`WeakSet` għall-metadata imkejjel b'oġġetti li m'għandhiex iżomm l-oġġetti fil-memorja.

## Għaliex Importanti

Memory leaks huma speċjalment perikolużi f'Node għaliex servers huma **long-running** — leak bil-mod li mhuwiex viżibbli fil-ħolqien gradualment imdegrada u eventwalment jaħraq proċess ta' produzzjoni (ħafna drabi jerġa' jibda u twieled ix-xogħol mid-dar).

L-għarfien tas-sorsi klassiċi (caches billi m'hemmx limiti, listeners/timers li ma ġiejtx neħħija, closures li jibqgħu), kif tiskopriha (heap monitoring + snapshot comparison ma' DevTools/clinic.js), u ir-riparazzjonijiet (bounded LRU caches, cleanup dixxiplinat, `WeakMap`) hu essenzjali għall-ħidma ta' servizzi Node affidabbli u stabbli matul il-ħin.