Memory Leak Detection Patterns

The Leaks Nobody Notices Until Production Burns

Here's the uncomfortable truth: most frontend apps are leaking memory right now. Not dramatically — not the kind that crashes the tab in 30 seconds. The insidious kind. The kind where your SPA runs fine for 10 minutes but gets sluggish after an hour. The kind that only shows up in production when real users navigate back and forth between views 50 times.

Memory leaks in frontend apps are fundamentally different from backend leaks. In a server, a leaked object might get cleaned up when the request ends. In a browser tab, a leaked object lives forever — or at least until the user refreshes. And modern SPAs can stay open for hours.

Pattern 1: Detached DOM Trees

This is the most common leak in SPAs and the hardest to spot. A detached DOM tree is a subtree of DOM nodes that has been removed from the document but is still referenced by JavaScript.

let cachedElement = null;

function showNotification(message) {
  const el = document.createElement('div');
  el.className = 'notification';
  el.textContent = message;
  document.body.appendChild(el);

  cachedElement = el;

  setTimeout(() => {
    el.remove();
  }, 3000);
}

After el.remove(), the DOM node is detached from the document tree. But cachedElement still holds a reference. The browser cannot garbage-collect that node — or any node it references (children, attributes, associated event handlers).

The scary part? A single leaked reference to one node in a tree keeps the entire tree alive. Reference a single <tr> in a 10,000-row table, and the whole table stays in memory.

function showNotification(message) {
  const el = document.createElement('div');
  el.className = 'notification';
  el.textContent = message;
  document.body.appendChild(el);

  setTimeout(() => {
    el.remove();
  }, 3000);
}

The fix is simple: don't store references to DOM nodes in long-lived variables. If you must cache, use WeakRef:

let cachedRef = null;

function cacheElement(el) {
  cachedRef = new WeakRef(el);
}

function getCached() {
  return cachedRef?.deref();
}

How to Detect in DevTools

1. Open Memory panel, take a heap snapshot
2. In the filter, type Detached
3. You will see Detached HTMLDivElement, Detached HTMLTableElement, etc.
4. Click any one to see its retaining path — this shows you exactly which JavaScript reference is keeping it alive

Pattern 2: Forgotten Event Listeners

Every addEventListener creates a reference from the target to the handler. If the target is window, document, or any long-lived DOM node, that reference persists until you explicitly removeEventListener.

function ChatRoom({ roomId }) {
  useEffect(() => {
    function onMessage(e) {
      console.log('Message:', e.data);
    }

    window.addEventListener('message', onMessage);

    // BUG: no cleanup — listener persists after unmount
  }, [roomId]);
}

Every time this component mounts with a new roomId, a new listener is added to window. Old listeners are never removed. After navigating between 100 rooms, you have 100 active listeners — each one closing over its own scope, keeping the component's variables alive.

function ChatRoom({ roomId }) {
  useEffect(() => {
    function onMessage(e) {
      console.log('Message:', e.data);
    }

    window.addEventListener('message', onMessage);

    return () => {
      window.removeEventListener('message', onMessage);
    };
  }, [roomId]);
}

The AbortController Pattern

Modern code can use AbortController for cleaner listener cleanup:

useEffect(() => {
  const controller = new AbortController();

  window.addEventListener('resize', handleResize, {
    signal: controller.signal,
  });
  window.addEventListener('scroll', handleScroll, {
    signal: controller.signal,
  });
  document.addEventListener('keydown', handleKey, {
    signal: controller.signal,
  });

  return () => controller.abort();
}, []);

One abort() call removes all three listeners. No mismatched references, no forgotten cleanup.

Pattern 3: Closures Over Large Scopes

We covered this in depth in the closures topic, but it is worth revisiting in the context of leak detection. Closures capture references to variables in their outer scope. If a closure lives longer than you expect, those variables stay alive too.

function processData() {
  const rawData = fetch('/api/huge-dataset').then(r => r.json());
  const hugeResult = transformData(rawData);

  return function getMetadata() {
    return { processedAt: Date.now(), count: hugeResult.length };
  };
}

getMetadata only needs hugeResult.length, but it closes over the entire hugeResult array. If hugeResult is 50MB, that 50MB stays alive as long as getMetadata exists.

The fix:

function processData() {
  const rawData = fetch('/api/huge-dataset').then(r => r.json());
  const hugeResult = transformData(rawData);
  const count = hugeResult.length;

  return function getMetadata() {
    return { processedAt: Date.now(), count };
  };
}

Extract the primitive values you need before creating the closure. Now hugeResult can be garbage collected after processData returns.

Pattern 4: Timer References

setInterval is the classic fire-and-forget leak. Unlike setTimeout (which fires once), setInterval keeps firing forever — and holds a reference to its callback and everything the callback closes over.

function startPolling(url) {
  const results = [];

  setInterval(async () => {
    const data = await fetch(url).then(r => r.json());
    results.push(data);
    updateUI(results);
  }, 5000);
}

results grows forever. The interval never stops. If startPolling is called when a component mounts but the interval is never cleared on unmount, you have a leak that grows every 5 seconds.

function startPolling(url) {
  const results = [];

  const intervalId = setInterval(async () => {
    const data = await fetch(url).then(r => r.json());
    results.push(data);
    updateUI(results);
  }, 5000);

  return () => clearInterval(intervalId);
}

// In React:
useEffect(() => {
  const stop = startPolling('/api/data');
  return stop;
}, []);

The setTimeout Loop Pattern

A safer alternative to setInterval:

function startPolling(url, signal) {
  async function poll() {
    if (signal.aborted) return;

    const data = await fetch(url, { signal }).then(r => r.json());
    updateUI(data);

    setTimeout(poll, 5000);
  }

  poll();
}

// Usage with AbortController
const controller = new AbortController();
startPolling('/api/data', controller.signal);

// To stop:
controller.abort();

The setTimeout loop is self-healing — if an error occurs or the signal is aborted, the chain breaks naturally. No orphaned intervals.

Pattern 5: Growing Arrays, Maps, and Sets

This is the sneakiest pattern because it is not a "leak" in the traditional sense — every reference is intentional. But unbounded growth has the same effect.

const eventLog = [];

function trackEvent(event) {
  eventLog.push({
    type: event.type,
    timestamp: Date.now(),
    data: structuredClone(event.data),
  });
}

If trackEvent runs on every user interaction and eventLog is never trimmed, you have linear memory growth. After a few hours, this array could hold hundreds of thousands of entries.

Prevention Strategies

const MAX_EVENTS = 1000;
const eventLog = [];

function trackEvent(event) {
  eventLog.push({
    type: event.type,
    timestamp: Date.now(),
    data: structuredClone(event.data),
  });

  if (eventLog.length > MAX_EVENTS) {
    eventLog.splice(0, eventLog.length - MAX_EVENTS);
  }
}

For caches, use a Map with LRU eviction or a WeakMap where appropriate:

const cache = new Map();
const MAX_CACHE = 100;

function cacheResult(key, value) {
  if (cache.size >= MAX_CACHE) {
    const firstKey = cache.keys().next().value;
    cache.delete(firstKey);
  }
  cache.set(key, value);
}

The Detection Workflow

Here is the systematic approach to finding memory leaks in production apps:

Real-World Leak: The React SPA Navigation Pattern

The most common real-world leak combines multiple patterns. Consider a dashboard SPA where users navigate between views:

let chartInstance = null;

function DashboardChart({ data }) {
  const canvasRef = useRef(null);

  useEffect(() => {
    chartInstance = new HeavyChartLibrary(canvasRef.current, {
      data,
      onHover: (point) => {
        showTooltip(point, data);
      },
    });

    return () => {
      // BUG: chartInstance.destroy() is called, but the
      // module-level variable still references the old instance
      chartInstance.destroy();
    };
  }, [data]);

  return <canvas ref={canvasRef} />;
}

This has three leak sources:

1. chartInstance (module-level) keeps the old chart alive after destroy
2. onHover closes over data, so the chart's internal listener keeps data alive
3. The chart library likely attaches listeners to the canvas, which is now detached

The fix:

function DashboardChart({ data }) {
  const canvasRef = useRef(null);

  useEffect(() => {
    const chart = new HeavyChartLibrary(canvasRef.current, {
      data,
      onHover: (point) => {
        showTooltip(point, data);
      },
    });

    return () => {
      chart.destroy();
    };
  }, [data]);

  return <canvas ref={canvasRef} />;
}

No module-level reference. The chart instance is local to the effect. When the cleanup runs, chart.destroy() tears down internal listeners, and the local variable goes out of scope.