JavaScript Memory Management Interview Questions

The memory lifecycle

Every value in JavaScript goes through three phases. Understanding each one reveals where leaks and inefficiencies happen.

// Phase 1: Allocation — memory is reserved when values are created
const name    = 'Alice'              // string allocated on heap
const nums    = [1, 2, 3]           // array + 3 numbers allocated
const user    = { id: 1, name }     // object allocated, name is a reference
function greet(n) { return `Hi ${n}` } // function object allocated

// Phase 2: Use — values are read, written, passed around
const greeting = greet(user.name)

// Phase 3: Release — GC frees memory when values become unreachable
// (happens automatically, at the engine's discretion)

Mark-and-sweep — how modern GC works

V8 (Chrome/Node.js), SpiderMonkey (Firefox), and JavaScriptCore (Safari) all use variants of mark-and-sweep garbage collection. The algorithm has two phases:

// Conceptually:

// MARK phase: GC starts from "roots" (global scope, call stack, registers)
// and traverses every reference, marking each reachable object

// SWEEP phase: GC walks the heap and frees every UNMARKED object

// Roots → reachable objects stay alive
// Objects not reachable from any root → freed

// Example:
function processOrder(orderId) {
  const order = fetchOrder(orderId)   // allocated
  const items = order.lineItems       // reference to nested array
  return summarize(items)
  // After this function returns:
  // 'order' and 'items' are no longer on the call stack
  // If nothing else references the order object → eligible for GC
}

// The GC doesn't run on every allocation — it runs in incremental
// batches, often triggered when the heap reaches a threshold

Generational garbage collection — young vs old heap

// V8 splits the heap into two generations:

// NEW SPACE (young generation) — small, collected frequently
// Most allocations start here — short-lived objects (local variables,
// temporary objects in loops) are created and collected here cheaply

// OLD SPACE (old generation) — large, collected infrequently
// Objects that survive multiple GC cycles are "promoted" to old space
// Old-space GC (major GC) is expensive — pauses are longer

// Implication for your code:
// Short-lived objects are cheap — JavaScript engines are optimized for them
// Long-lived objects (module-level caches, singletons) are fine too
// The expensive case: objects that look temporary but stay alive longer
// than expected, flooding old space — this is how leaks manifest

// Creating many large objects with unpredictable lifetimes causes
// "GC pressure" — the collector runs more frequently, causing jank

The four classic memory leak patterns

// LEAK 1: Accidental global variables
function processData(data) {
  result = transform(data)  // forgot 'const' — result is now a global!
}
// 'result' lives on the window object forever — never collected

// Fix: always use const/let, use 'use strict' (which throws on undeclared assignment)

// LEAK 2: Event listeners never removed
class SearchBox {
  constructor(input) {
    this.input = input
    this.results = new LargeResultsCache()

    // This closure keeps 'this' (and therefore results) alive
    // as long as the input element exists in the DOM
    document.addEventListener('keydown', (e) => {
      this.results.filter(e.key)
    })
    // Even if SearchBox is "destroyed", the listener is still registered
    // on document — the entire SearchBox instance is kept alive
  }
}

// Fix: store the handler reference and remove it on cleanup
class SearchBox {
  constructor(input) {
    this.input   = input
    this.results = new LargeResultsCache()
    this._handler = (e) => this.results.filter(e.key)
    document.addEventListener('keydown', this._handler)
  }
  destroy() {
    document.removeEventListener('keydown', this._handler)
  }
}

// LEAK 3: Detached DOM nodes
let detachedTree

function createTree() {
  const div = document.createElement('div')
  div.appendChild(document.createElement('p'))
  detachedTree = div  // stored in a module-level variable
}

document.getElementById('btn').addEventListener('click', () => {
  document.body.removeChild(document.body.lastChild)
})
// The DOM node is removed from the document, but 'detachedTree' still
// holds a reference — the entire node tree stays in memory

// Fix: null out the reference when the node is removed
detachedTree = null

// LEAK 4: Closures capturing large objects unintentionally
function setupHandler(largeData) {
  const summary = summarize(largeData)  // small — only what you need

  return function handler() {
    console.log(summary)
    // If you had referenced largeData instead of summary,
    // the entire largeData object would be captured in this closure
    // and kept alive as long as handler is alive
  }
}
// Fix: extract only what you need before creating the closure

WeakMap and WeakSet — GC-friendly references

// Regular Map — holds STRONG references — keys are never GC'd
const cache = new Map()
cache.set(domNode, { clicks: 0 })
// Even if domNode is removed from the DOM and all other references are gone,
// the Map keeps it alive — because Map holds a strong reference to the key

// WeakMap — holds WEAK references to keys
// If the key object has no other references, GC can collect it
// AND the WeakMap entry is automatically removed
const weakCache = new WeakMap()
weakCache.set(domNode, { clicks: 0 })
// When domNode is removed from DOM and dereferenced elsewhere,
// GC collects domNode — the WeakMap entry disappears too

// WeakMap use cases:
// 1. Per-object metadata without preventing GC
const metadata = new WeakMap()
function trackClicks(element) {
  if (!metadata.has(element)) metadata.set(element, { clicks: 0 })
  metadata.get(element).clicks++
}

// 2. Private data for class instances (pre-private fields)
const _private = new WeakMap()
class Secure {
  constructor(secret) {
    _private.set(this, { secret })
  }
  getSecret() {
    return _private.get(this).secret
  }
}
// When instance is GC'd, WeakMap entry is GC'd too — no leak

// WeakRef — direct weak reference to an object
const ref = new WeakRef(largeObject)
// Later:
const obj = ref.deref()  // returns the object if still alive, undefined if GC'd
if (obj) {
  process(obj)
} else {
  // Object was collected — rebuild or skip
}

Memory-efficient patterns

// Object pooling — reuse objects instead of allocating/discarding
class ParticlePool {
  constructor(size) {
    this.pool      = Array.from({ length: size }, () => ({ x: 0, y: 0, active: false }))
    this.available = [...this.pool]
  }

  acquire() {
    return this.available.pop() || { x: 0, y: 0, active: false }
  }

  release(particle) {
    particle.active = false
    this.available.push(particle)  // return to pool for reuse
  }
}
// Game engines, canvas animations, and real-time data processing use this
// pattern to avoid GC pressure from thousands of short-lived allocations

// Avoid memory-heavy closures in tight loops
const buttons = document.querySelectorAll('button')

// ❌ Creates a new function object per element
buttons.forEach((btn, i) => {
  btn.addEventListener('click', () => handleClick(i))  // new fn each iteration
})

// ✓ One shared handler, data stored on the element
buttons.forEach((btn, i) => {
  btn.dataset.index = i
  btn.addEventListener('click', sharedHandler)
})
function sharedHandler(e) {
  handleClick(Number(e.currentTarget.dataset.index))
}

Measuring memory in the browser

// Chrome DevTools Memory tab:
// Heap snapshot — shows all live objects and their sizes
// Allocation timeline — records allocations over time
// Allocation sampling — lightweight continuous profiling

// In code:
performance.memory  // Chrome-only, non-standard
// { usedJSHeapSize, totalJSHeapSize, jsHeapSizeLimit }

// Detecting a leak:
// 1. Take heap snapshot (baseline)
// 2. Perform the suspected leaking action 5–10 times
// 3. Force GC (DevTools Memory panel has a GC button)
// 4. Take another heap snapshot
// 5. Compare — if heap size grows linearly with action count, you have a leak
// 6. Filter snapshot by "Objects allocated between snapshot 1 and 2"
// 7. Look for unexpectedly retained Detached HTMLElements or closures