What causes memory leaks in JavaScript?

Question

Accepted Answer

JavaScript's garbage collector automatically frees memory that is no longer reachable from the root. A memory leak occurs when the application holds onto references that keep objects reachable long after they are needed, causing memory usage to grow continuously. These leaks often result from subtle programming patterns that create lingering references, especially in long-running applications like single-page apps or Node.js servers where accumulated memory can eventually cause crashes or severe performance degradation. **Undeclared variables**: Assigning a value to an undeclared variable automatically creates a property on the global object (window in browsers, global in Node.js). This reference persists for the entire application lifetime . **'this' in global scope**: In non-strict mode, using `this` in a function that is called without an explicit receiver also references the global object . **Unintentional globals**: Forgetting `var`, `let`, or `const` is the most common source. Even primitives become problematic if they reference larger structures . **Solution**: Use strict mode (`'use strict';`), linting tools (ESLint), and module bundlers that prevent accidental globals . // Problem: Undeclared variable becomes global
function process(data) {
  result = data * 2;  // No 'let'/'const'/'var' - global!
  return result;
}

// Problem: 'this' in non-strict mode
function leak() {
  this.someData = new Array(10000);  // 'this' is global!
}
leak();  // No new keyword, 'this' = global object

// Solution: Use strict mode
'use strict';
function safe() {
  this.someData = new Array(10000);  // 'this' is undefined - throws error
}

// Always use 'let' or 'const'
function process(data) {
  const result = data * 2;
  return result;
} **DOM event listeners**: Adding event listeners to DOM elements without removing them keeps both the listener function and the DOM element alive, even after the element is removed from the page . **Custom event emitters**: In Node.js or browser custom events, listeners attached to EventEmitters must be removed when no longer needed . **Observer patterns**: MutationObserver, ResizeObserver, and similar APIs retain references to their callbacks and observed targets until disconnected . **Solution**: Always remove listeners with `removeEventListener`, `off`, or `disconnect()` when components unmount or elements are removed. Use weak references where available (WeakMap for metadata) . // Problem: Listener never removed
class Component {
  constructor(element) {
    this.element = element;
    element.addEventListener('click', this.handleClick);
  }
  
  handleClick = () => {
    console.log('clicked');
  }
  
  destroy() {
    // Forgot to remove listener!
    // Element and component stay in memory
  }
}

// Solution: Clean up properly
class Component {
  constructor(element) {
    this.element = element;
    this.handleClick = this.handleClick.bind(this);
    element.addEventListener('click', this.handleClick);
  }
  
  handleClick() {
    console.log('clicked');
  }
  
  destroy() {
    this.element.removeEventListener('click', this.handleClick);
  }
} **Hidden references**: Storing DOM elements in JavaScript variables or data structures while they are removed from the page keeps them in memory . **Closures capturing DOM**: Functions that close over DOM nodes keep those nodes alive as long as the function exists . **Caches of DOM elements**: Caching query results or storing elements in maps/arrays without cleanup . **Solution**: Nullify references when done, use WeakMap for DOM metadata, and be careful what closures capture . // Problem: Storing removed elements
let button = document.getElementById('submit');
let cache = [];

function processButton() {
  cache.push(button);  // Store reference
  button.remove();     // Remove from DOM
  // button still in cache - element remains in memory!
}

// Problem: Closures capturing DOM
function setup() {
  const element = document.getElementById('test');
  
  window.addEventListener('resize', () => {
    console.log(element.clientWidth); // 'element' captured!
  });
  // element will never be GC'd because closure keeps reference
}

// Solution: Clear references
function processButton() {
  let button = document.getElementById('submit');
  // Do work
  button.remove();
  button = null;  // Allow GC
}

// For closures, use weak references or avoid capturing **setInterval without clear**: Functions scheduled with setInterval run forever and keep their entire lexical environment alive unless cleared . **setTimeout chains**: Recursive setTimeout patterns can accumulate if not properly managed . **Large captured scopes**: Closures that capture large objects keep those objects alive even if the closure only needs a small part . **Solution**: Always clear intervals/timeouts with `clearInterval`/`clearTimeout`. Be mindful of what closures capture—use only needed variables or copy primitives . // Problem: setInterval never cleared
function startUpdates()

What causes memory leaks in JavaScript?

Memory leaks in JavaScript are caused by unintentionally retaining references to objects that are no longer needed, preventing the garbage collector from reclaiming their memory and leading to gradual memory exhaustion.

What causes memory leaks in JavaScript?

Memory leaks in JavaScript are caused by unintentionally retaining references to objects that are no longer needed, preventing the garbage collector from reclaiming their memory and leading to gradual memory exhaustion.

Scenario Questions

Follow-up Questions