Memory Leak Patterns

Memory Leaks in a Garbage-Collected Language

"JavaScript has garbage collection, so memory leaks can't happen." You've heard this, maybe even believed it. It's wrong. The GC collects unreachable objects. A memory leak occurs when objects remain reachable but are no longer needed. The GC can't read your mind — it only follows references.

// This is a memory leak
const cache = [];
function processRequest(data) {
  const result = heavyComputation(data);
  cache.push(result);  // Never removed — cache grows without bound
  return result;
}

The cache array is reachable from module scope. Every result added is kept alive forever. The GC sees a perfectly valid reference chain: global → module → cache → results. It has no way to know you don't need results from 10,000 requests ago.

Pattern 1: Forgotten Event Listeners

This is the number one leak in web applications, bar none. Every addEventListener creates a reference from the DOM node to the callback. If the callback closes over application state, that state is kept alive as long as the listener exists.

// LEAK: listener is never removed
function initFeature() {
  const data = loadLargeDataset();  // 50 MB of data

  window.addEventListener('scroll', () => {
    updateVisualization(data);  // Closure holds 'data' alive
  });
}

// Feature is "destroyed" but the listener remains
// 'data' (50 MB) is still reachable through the listener's closure

The fix is always the same: store the reference and remove the listener when done:

function initFeature() {
  const data = loadLargeDataset();

  const onScroll = () => updateVisualization(data);
  window.addEventListener('scroll', onScroll);

  // Return a cleanup function
  return () => {
    window.removeEventListener('scroll', onScroll);
    // 'data' becomes unreachable once the closure is gone
  };
}

const cleanup = initFeature();
// Later, when feature is no longer needed:
cleanup();

// CAN'T remove this — the arrow function is anonymous
element.addEventListener('click', () => handleClick());

// CAN remove this — named function reference
const handler = () => handleClick();
element.addEventListener('click', handler);
element.removeEventListener('click', handler);

Pattern 2: Closures Over Large Scopes

This one surprises people. Closures capture their entire lexical scope — not just the variables they actually use. If a closure captures one variable from a scope that also contains large objects, those large objects are retained too.

function processData() {
  const rawData = fetchHugePayload();      // 200 MB
  const summary = computeSummary(rawData);  // 1 KB

  // This closure only uses 'summary', but captures the entire scope
  return function getSummary() {
    return summary;
  };
}

const getter = processData();
// rawData (200 MB) is still in memory — captured by the closure's scope

function processData() {
  const summary = computeSummary(fetchHugePayload());
  // rawData was never a variable — it's immediately consumed
  return function getSummary() {
    return summary;
  };
}

Pattern 3: Detached DOM Trees

Here's one that's particularly nasty to debug. A detached DOM tree is a subtree of DOM nodes removed from the document but still referenced in JavaScript. The entire subtree stays in memory.

let cachedElement = null;

function showModal() {
  const modal = document.createElement('div');
  modal.innerHTML = `<div class="modal">
    <div class="content"><!-- large subtree --></div>
  </div>`;
  document.body.appendChild(modal);
  cachedElement = modal;  // JS reference
}

function hideModal() {
  cachedElement.remove();  // Removed from DOM...
  // ...but 'cachedElement' still holds a reference
  // The entire modal subtree is a detached DOM tree — still in memory
}

The fix: null out the reference after removal:

function hideModal() {
  cachedElement.remove();
  cachedElement = null;  // Release the reference
}

But wait, it gets worse. A single reference to any node in the tree keeps the entire tree alive:

function setupTable() {
  const table = document.createElement('table');
  // ... add 1000 rows
  document.body.appendChild(table);

  const firstCell = table.querySelector('td');
  // 'firstCell' keeps the entire table alive even after removal
  return firstCell;
}

const cell = setupTable();
document.querySelector('table').remove();
// Table is detached but cell → row → tbody → table → all 1000 rows still in memory

Pattern 4: Uncleared Timers and Intervals

setInterval creates a recurring reference that persists until explicitly cleared:

function startPolling(url) {
  const data = { buffer: new ArrayBuffer(1024 * 1024) };  // 1 MB

  setInterval(() => {
    fetch(url).then(res => {
      // Process response using data.buffer
      processWithBuffer(res, data.buffer);
    });
  }, 5000);
  // Interval runs forever. Closure keeps 'data' alive forever.
}

// Even if the component unmounts, the interval continues

The fix: store the interval ID and clear it:

function startPolling(url) {
  const data = { buffer: new ArrayBuffer(1024 * 1024) };

  const intervalId = setInterval(() => {
    fetch(url).then(res => processWithBuffer(res, data.buffer));
  }, 5000);

  return () => {
    clearInterval(intervalId);
    // data.buffer becomes eligible for GC
  };
}

const stopPolling = startPolling('/api/status');
// Later:
stopPolling();

setTimeout is less dangerous (it fires once and the closure can be collected after), but recursive setTimeout has the same issue as setInterval.

Pattern 5: Growing Caches Without Eviction

This is the most subtle leak of all — because it looks like perfectly reasonable code:

const cache = new Map();

function getUser(id) {
  if (cache.has(id)) return cache.get(id);
  const user = fetchUserSync(id);
  cache.set(id, user);  // Entry added, never removed
  return user;
}
// After 100,000 unique users: 100,000 cached user objects

Caches need eviction policies:

class LRUCache {
  #map = new Map();
  #maxSize;

  constructor(maxSize) {
    this.#maxSize = maxSize;
  }

  get(key) {
    if (!this.#map.has(key)) return undefined;
    const value = this.#map.get(key);
    // Move to end (most recently used)
    this.#map.delete(key);
    this.#map.set(key, value);
    return value;
  }

  set(key, value) {
    if (this.#map.has(key)) this.#map.delete(key);
    this.#map.set(key, value);
    // Evict oldest if over capacity
    if (this.#map.size > this.#maxSize) {
      const oldestKey = this.#map.keys().next().value;
      this.#map.delete(oldestKey);
    }
  }
}

This uses the fact that JavaScript Map preserves insertion order — keys().next().value is the oldest entry.

Pattern 6: Global References and Module-Level State

// module-level.js
const subscribers = [];

export function subscribe(callback) {
  subscribers.push(callback);
}

export function unsubscribe(callback) {
  const idx = subscribers.indexOf(callback);
  if (idx !== -1) subscribers.splice(idx, 1);
}

// consumer.js — LEAK: forgets to unsubscribe
import { subscribe } from './module-level.js';

function init() {
  const heavyState = loadState();  // 50 MB
  subscribe(() => render(heavyState));
  // If this component is destroyed without calling unsubscribe,
  // the closure (and heavyState) is retained in the subscribers array
}

Debugging: Heap Snapshot Comparison

Now let's talk about actually finding these leaks. The most reliable technique is heap snapshot comparison:

1. Take snapshot A (baseline): after the app has been running normally
2. Perform the suspected leaking action (navigate to a page, open/close a modal, etc.)
3. Return to baseline state (navigate back, close the modal)
4. Force garbage collection (click the trash can icon in DevTools Memory panel)
5. Take snapshot B (after returning to baseline)
6. Compare B to A: any objects in B that weren't in A are potential leaks

In Chrome DevTools:

• Open Memory tab → select Heap snapshot
• Take first snapshot → perform action → undo action → take second snapshot
• Select second snapshot → change view to Comparison → select first snapshot as baseline
• Sort by Size Delta or Count Delta to find growing object types

Production Leak Detection

The Sawtooth Pattern

Once you know what to look for, you can spot leaks from a memory graph alone. A healthy application shows a sawtooth pattern: memory rises as objects are allocated, drops when GC collects them, rises again:

Memory
  |  /|  /|  /|  /|
  | / | / | / | / |
  |/  |/  |/  |/  |
  └──────────────── Time

A leaking application shows a rising sawtooth: each peak is higher than the last because some objects survive every GC cycle:

Memory
  |          /|  /|
  |       /|/ |/ |
  |    /|/ |  |  |
  | /|/ |  |  |  |
  |/ |  |  |  |  |
  └──────────────── Time

Automated Leak Detection

// Simple production leak detector
const SAMPLE_INTERVAL = 60_000; // 1 minute
const TREND_WINDOW = 10;        // 10 samples = 10 minutes

const memorySamples = [];

setInterval(() => {
  if (globalThis.gc) globalThis.gc(); // Only if --expose-gc
  const usage = process.memoryUsage();

  memorySamples.push(usage.heapUsed);
  if (memorySamples.length > TREND_WINDOW) memorySamples.shift();

  if (memorySamples.length === TREND_WINDOW) {
    const isRising = memorySamples.every((val, i) =>
      i === 0 || val > memorySamples[i - 1]
    );
    if (isRising) {
      console.error(`Potential memory leak: heap grew monotonically over ${TREND_WINDOW} minutes`);
    }
  }
}, SAMPLE_INTERVAL);

Key Rules