Bagaimanakah anda mengesan dan membetulkan kebocoran memori dalam Node.js?

Question

IT Interview Practice · Accepted Answer

**Kebocoran memori** ialah memori yang tidak lagi diperlukan tetapi tidak pernah dibebaskan, kerana sesuatu masih merujuknya. Lama-kelamaan heap proses tersebut membesar sehingga ia menjadi perlahan atau terhempas (kehabisan memori). Dalam pelayan Node yang berjalan lama, kebocoran adalah kebimbangan pengeluaran yang serius.

## Sumber kebocoran biasa

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

Benang sepunya: rujukan yang boleh dicapai (Map global, listener yang hidup, timer yang berjalan, closure) menghalang objek daripada dikutip sampah (garbage-collected) walaupun ia tidak lagi berguna.

## Mengesan kebocoran

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

Proses diagnostik: sahkan bahawa heap membesar dengan stabil (bukan sekadar turun naik biasa), kemudian ambil **heap snapshots** sebelum/selepas beban kerja dan bandingkan untuk mencari jenis objek yang sedang terkumpul ("retained size" yang membesar).

## Membetulkan kebocoran

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

Pembetulan mencerminkan puncanya: hadkan caches (LRU dengan saiz maksimum/TTL), sentiasa pasangkan penciptaan listener/timer dengan pembersihan, dan gunakan `WeakMap`/`WeakSet` untuk metadata berkunci objek yang tidak sepatutnya menyemat objek dalam memori.

## Mengapa ia penting

Kebocoran memori amat berbahaya dalam Node kerana pelayan **berjalan lama** — kebocoran perlahan yang tidak kelihatan semasa pembangunan beransur-ansur merosot dan akhirnya menghempaskan proses pengeluaran (selalunya memulakan semula dan kehilangan kerja yang sedang dalam proses).

Mengetahui sumber klasik (caches tanpa had, listeners/timers yang tidak dialih keluar, closures yang berlarutan), cara mengesannya (pemantauan heap + perbandingan snapshot dengan DevTools/clinic.js), dan pembetulannya (caches LRU berhad, pembersihan berdisiplin, `WeakMap`) adalah penting untuk mengendalikan perkhidmatan Node yang boleh dipercayai dan stabil dari masa ke masa.

Sumber kebocoran biasa

Mengesan kebocoran

Membetulkan kebocoran

Mengapa ia penting

Soalan berkaitan