JavaScript Closures — Loop Traps and Memory Leak Patterns

How Closures Actually Work — And Why They Leak

A closure is a function that retains access to its lexical scope even when executed outside that scope. The core mechanic: every function carries a hidden reference to the environment where it was defined, keeping that environment's variables alive. This is not magic — it's a pointer to a scope object that persists as long as any closure references it.

In practice, closures capture variables by reference, not by value. This means all closures created in the same scope share the same mutable variable, not a snapshot of its value at creation time. This is the root of the classic loop trap: for (var i = 0; i < 5; i++) { setTimeout(() => console.log(i), 0) } logs 5 five times, not 0-4, because each closure references the same i after the loop finishes.

Use closures for data encapsulation, partial application, and maintaining state across async operations. They are essential in event handlers, callbacks, and module patterns. But every closure that outlives its creator creates a retention path — if that path includes large objects or DOM nodes, you get memory leaks that degrade performance over time.

How Closures Work

A closure is created automatically whenever a function is defined inside another function and the inner function references variables from the outer function's scope. The inner function 'closes over' those variables, keeping them alive even after the outer function has finished executing. This is possible because JavaScript functions carry their lexical environment — the set of variables in scope at definition time — with them as an internal property. Every function in JavaScript is a closure over at least the global scope.

function makeCounter(start = 0) {
  let count = start;  // this variable lives in makeCounter's scope

  return {
    increment() { count++; },
    decrement() { count--; },
    value()     { return count; }
  };
  // makeCounter returns and its stack frame is gone
  // but count survives because the returned object closes over it
}

const counter = makeCounter(10);
counter.increment();
counter.increment();
counter.decrement();
console.log(counter.value()); // 11

// Two independent counters — each has its own count
const a = makeCounter(0);
const b = makeCounter(100);
a.increment();
a.increment();
b.increment();
console.log(a.value()); // 2
console.log(b.value()); // 101 — b has its own count

Lexical Environment Flow Visualization

To understand closures, you must understand lexical environments. Each time a function is called, JavaScript creates a new lexical environment — a data structure that holds the local variables and a reference to the outer environment. The inner function’s [[Environment]] internal slot points to the outer function’s lexical environment at the time the inner function is created. When you invoke the inner function, its own lexical environment is created with a reference to that stored outer environment, giving it access to the outer variables even after the outer function has returned. This chain of environments is the closure scope chain. The diagram below shows two independent makeCounter calls: each call creates its own lexical environment for count, and each returned object’s methods retain a reference to that specific environment.

// Lexical environment chain visualized:
function makeCounter(start) {
  let count = start;               // LexicalEnvironment A: { count: start }
  return {
    increment() { count++; },      // [[Environment]] -> A
    value() { return count; }       // [[Environment]] -> A
  };
}

const c1 = makeCounter(0);  // creates LE A1 with count=0
const c2 = makeCounter(10); // creates LE A2 with count=10
// c1.value's [[Environment]] points to A1, c2.value's points to A2

The Classic Loop Closure Trap

One of the most common JavaScript interview questions. The surprise: var-declared loop variables are shared across all closures created in the loop. Each closure created in the loop body captures the same variable, not a copy of its value at creation time. By the time the closures execute, the loop has already finished and the variable holds its final value. The fix is to use let, which creates a new binding per iteration, or to wrap the closure in an IIFE that captures the current value.

// The trap — using var
const fns = [];
for (var i = 0; i < 3; i++) {
  fns.push(() => console.log(i));
}
fns[0](); // 3 — not 0!
fns[1](); // 3
fns[2](); // 3
// Why? var has function scope, not block scope.
// All three closures share the SAME i variable.
// By the time they run, i is already 3.

// Fix 1: use let (block-scoped — a new binding per iteration)
const fns2 = [];
for (let i = 0; i < 3; i++) {
  fns2.push(() => console.log(i));
}
fns2[0](); // 0 ✓
fns2[1](); // 1 ✓
fns2[2](); // 2 ✓

// Fix 2: IIFE to capture the current value (pre-ES6)
const fns3 = [];
for (var i = 0; i < 3; i++) {
  fns3.push(((capturedI) => () => console.log(capturedI))(i));
}
fns3[0](); // 0 ✓

Var vs Let — Loop Behavior Visual Comparison

The following visual sequence shows how var and let behave differently inside a loop that creates closures. With var, all closures see the same i variable which lives in the function scope. After the loop finishes, i equals the exit condition (3). When any closure is called later, it logs 3. With let, the JavaScript engine creates a new lexical binding for i in each iteration. Each closure captures its own unique binding. The array steps below illustrate the state of i at the moment each closure is created and the value it eventually logs.

// Visual demonstration:
const varFns = [];
const letFns = [];

for (var i = 0; i < 3; i++) {
  varFns.push(() => console.log('var:', i));
}

for (let j = 0; j < 3; j++) {
  letFns.push(() => console.log('let:', j));
}

// All closures execute after both loops finish
varFns.forEach(fn => fn()); // var: 3, var: 3, var: 3
letFns.forEach(fn => fn()); // let: 0, let: 1, let: 2

Practical Pattern — Memoization

Closures are perfect for memoization: a function that caches its results so expensive calculations are only done once. The cache is stored in a closure variable, invisible to the outside world. Each call to the memoized function first checks the cache; if the result exists, it returns immediately. This pattern is deceptively simple but requires care: if the arguments are complex objects, JSON.stringify may not produce a stable key, and large caches can cause memory leaks if not bounded.

function memoize(fn) {
  const cache = new Map();  // closed over by the returned function

  return function(...args) {
    const key = JSON.stringify(args);
    if (cache.has(key)) {
      console.log(`Cache hit for ${key}`);
      return cache.get(key);
    }
    const result = fn(...args);
    cache.set(key, result);
    return result;
  };
}

const expensiveSqrt = memoize((n) => {
  console.log(`Computing sqrt(${n})...`);
  return Math.sqrt(n);
});

console.log(expensiveSqrt(16));  // Computing sqrt(16)... → 4
console.log(expensiveSqrt(16));  // Cache hit for [16]   → 4
console.log(expensiveSqrt(25));  // Computing sqrt(25)... → 5

Closures and the Module Pattern

Before ES6 modules, JavaScript developers used closures to create private state and public APIs — a pattern called the Module Pattern. An IIFE (Immediately Invoked Function Expression) creates a scope where variables are hidden from the outside. The IIFE returns an object whose methods are closures over those private variables. This pattern is still useful when you want to encapsulate logic without a class or when working in environments without module support.

const UserModule = (function() {
  let users = []; // private — cannot be accessed from outside

  function addUser(name) {
    if (!name) throw new Error('Name required');
    users.push({ name, createdAt: Date.now() });
  }

  function getUsers() {
    return users.map(u => u.name); // returns a copy of names
  }

  function count() {
    return users.length;
  }

  return {
    addUser,
    getUsers,
    count
  };
})();

UserModule.addUser('Alice');
UserModule.addUser('Bob');
console.log(UserModule.getUsers()); // ['Alice', 'Bob']
console.log(UserModule.count());    // 2
// UserModule.users is undefined — truly private

Closure-based Module Pattern (Private Variables) Section

While the classic module pattern uses an IIFE to create singleton encapsulation, you can also create reusable closures that manage private state per call, similar to classes but without prototypal overhead. This section shows an alternative approach: a factory function that returns an object with methods closing over truly private variables. Unlike the IIFE singleton, each factory call creates independent private instances. This pattern is often used for managing configuration, database connections, or service wrappers where each instance needs its own hidden state.

function createSecureCounter(secretToken) {
  // Private variables – not exposed
  let count = 0;
  const token = secretToken;

  function validateToken(t) {
    return t === token;
  }

  return {
    increment(t) {
      if (!validateToken(t)) throw new Error('Invalid token');
      count++;
    },
    getCount(t) {
      if (!validateToken(t)) throw new Error('Invalid token');
      return count;
    },
    reset(t) {
      if (!validateToken(t)) throw new Error('Invalid token');
      count = 0;
    }
  };
}

const counterAlice = createSecureCounter('alice-secret');
counterAlice.increment('alice-secret');
console.log(counterAlice.getCount('alice-secret')); // 1
// counterAlice.count is undefined
// counterAlice.token is undefined
// No one can access the token or count from outside

const counterBob = createSecureCounter('bob-secret');
counterBob.increment('bob-secret');
console.log(counterBob.getCount('bob-secret')); // 1
// Independe|nt state

Closures and Memory Leaks

Closures can cause memory leaks when they hold references to large objects long after those objects are needed. This commonly happens with event listeners that aren't removed, setInterval/setTimeout callbacks that outlive their components, or closures that capture entire parent scopes via 'this'. Modern JavaScript engines are smart — they only keep referenced variables, not the entire scope — but accidental references via closures are still the #1 cause of memory leaks in frontend applications.

// Memory leak example: setInterval callback captures large data
function startUpdater() {
  const hugeData = fetchHugeDataset(); // large array of objects
  const intervalId = setInterval(() => {
    // This closure captures hugeData — it stays in memory forever
    updateUI(hugeData);
  }, 1000);

  // If startUpdater is called multiple times without clearing,
  // each interval holds its own hugeData reference.
  return () => clearInterval(intervalId); // cancel function returned
}

// Fix: clear interval when no longer needed, or pass only necessary data
function startUpdaterFixed() {
  const intervalId = setInterval(() => {
    // Fetch fresh data each time, or use a reference that can be cleaned up
    updateUI(getSmallDataset());
  }, 1000);
  return () => clearInterval(intervalId);
}

// Another pattern: use WeakRef for large objects that can be GC'd
// But WeakRef is rarely the right answer — usually just don't capture large objects.

Why Lexical Scoping Decides Everything — And Where It Breaks

Most junior devs think closures are magic. They're not. Closures rely on lexical scoping, which is just a fancy name for "where you wrote the function determines what variables it can see." No runtime trickery. The JavaScript engine reads your source code at parse time and builds a scope tree. When you nest a function inside another, the inner function inherits access to all variables from every ancestor scope. That's the why. The how is a hidden internal object called the LexicalEnvironment. Every execution context has one. It stores variables as property bindings. When your function tries to read a variable, the engine walks the chain: current context → parent context → parent's parent → until it hits the global scope or finds the variable. This walks at runtime, but the structure is fixed at parse time. Here's the trap: let and const are block-scoped; var is function-scoped. Use let inside a loop's block and each iteration gets its own binding. Use var and every closure in that loop shares the same binding — the final value. That's not a bug. That's you not understanding lexical scope. Fix your mental model before you write another line.

// io.thecodeforge
function reportUser(prefix) {
  const userId = 4829;
  function internalStatus() {
    // captures prefix and userId from lexical environment
    const status = "active";
    function deepLog() {
      // walks scope chain: self -> internalStatus -> reportUser -> global
      console.log(`${prefix}${userId}: ${status}`);
    }
    return deepLog;
  }
  return internalStatus();
}

const logger = reportUser("USR-");
logger(); // "USR-4829: active"

The Loop Trap That Burned Me Twice — Var vs Let Under Closure

I shipped a bug that took down a production scheduler because I used var in a for loop and thought each iteration created a separate closure variable. It didn't. The root cause: var is function-scoped, not block-scoped. Every closure inside that loop referenced the same i variable — the one that ended at the loop's final value. So all scheduled callbacks fired with i = 5 instead of their intended index. The fix: use let. The ES6 spec turned let into a per-iteration binding inside for loops. Each iteration gets its own lexical environment with a fresh copy of i. That's the why. Here's the how: the engine creates a new declarative environment record for each loop iteration when you use let. It copies the previous iteration's value, then increments. Each closure captures that unique environment. No sharing. No bugs. Visualize it: imagine separate boxes per iteration, each with its own i. That's the spec. var gives you one box that everyone overwrites. Don't argue with the engine. Use let for loops and save yourself the 2 AM pager call.

// io.thecodeforge
const scheduleTasks = (tasks) => {
  for (let i = 0; i < tasks.length; i++) {
    setTimeout(() => {
      console.log(`Processing task ${i}: ${tasks[i]}`);
      // i is captured per-iteration with let
      // swap 'let' to 'var' and every log prints "3: undefined"
    }, i * 100);
  }
};

scheduleTasks(['cleanup', 'backup', 'notify']);