Closures in loops, timers & memory

The problem closures create

Closures are not a rare advanced trick. Every function you create keeps access to the place where it was created. That power is why callbacks, factories, private state, memoize caches, and event handlers work.

The surprise is that a closure remembers bindings, not a frozen picture of every value. If the function runs later, the binding it reads may have changed. If the app replaced state with a new object, the closure may still read the old object. If a function lives for a long time, anything it still reaches can stay in memory too.

The Closures lesson introduced the idea that closures retain bindings, not snapshots. This lesson goes deeper into the classics you will debug in real code: loop callbacks, timers, stale callbacks, and accidental memory retention.

The famous closure puzzle is small enough to fit on three lines. With var, the callbacks print 3, 3, 3. With let, they print 0, 1, 2. The callbacks are not different; the binding named i is different.

Run the replay twice. First leave it on var and watch the one binding change. Then switch to let and notice that each scheduled callback points at its own iteration binding.

1for (var i = 0; i < 3; i++) {Run2  setTimeout(() => console.log(i), 0);3}

The full Timers and Event loop lessons arrive in Stage 6. For today, keep one simple rule: setTimeout asks the host to call a function later. JavaScript continues running the current code. A loop finishes before those timer callbacks run.

The callback is created during the loop. The console.log inside it runs later. This timing difference is the whole trick.

Good fixes give each callback a fresh binding or pass it the current value. Modern code usually uses let in the loop header. Older code may use an IIFE. Timer code can pass extra arguments to setTimeout. Array iteration methods such as forEach also give each callback call its own parameter.

1for (var i = 0; i < 3; i++) {Run2  setTimeout((n) => console.log(n), 0, i);3}

A stale closure is a callback that reads something that was accurate when the callback was created, but is no longer the current source of truth. This happens a lot in UI code because apps often replace state objects instead of mutating the same object.

In this plain JavaScript example, settings is replaced. The old callback reads captured, which still points at the original object.

1let settings = { label: "slow" };Run2 3function startTicker() {4  const captured = settings;5  return () => console.log(captured.label);6}7 8const tick = startTicker();9settings = { label: "fast" };10tick();

let settings = { label: "slow" };

function startTicker() {
  const captured = settings;
  return () => console.log(captured.label);
}

const tick = startTicker();
settings = { label: "fast" };
tick();

The Memory: primitives vs objects lesson introduces reachability and garbage collection basics. A value can be collected only when nothing reachable points to it. A long-lived closure is reachable through the function object, so values it closes over can remain reachable too.

function makeReport() {
  const rows = new Array(1_000_000).fill("row");
  return () => rows.length;
}

const report = makeReport();
console.log(report());

function makeReport() {
  const rows = new Array(1_000_000).fill("row");
  return () => rows.length;
}

const report = makeReport();
console.log(report());

function makeReport() {
  const rows = new Array(1_000_000).fill("row");
  const rowCount = rows.length;
  return () => rowCount;
}

const report = makeReport();
console.log(report());

When you intentionally keep a cache in a closure, make the retention a design choice: size-limit it, expose a clear method, or use WeakMap when object keys should not be kept alive by the cache itself. The later Finding memory leaks lesson shows heap snapshots for proving these chains in real applications.

Where you will use this

You will use these rules whenever code runs later than where it was written: timers, intervals, event listeners, animation callbacks, subscriptions, retries, and UI handlers. Professional debugging often means drawing two timelines: when the callback was created, and when it actually ran.

function startPolling(readUrl) {
  const id = setInterval(() => {
    console.log("poll", readUrl());
  }, 1000);

  return () => clearInterval(id);
}

The returned cleanup function closes over the timer id on purpose. The interval callback reads the URL through a function, so it can stay fresh. The cleanup closes the reachability chain when polling stops.

Common misconceptions

• “Closures copy values.” They retain access to bindings. A changed binding can be read later.
• “setTimeout with 0 runs immediately.” It still runs after the current synchronous code finishes.
• “const prevents stale closures.” const prevents reassignment of that binding; it does not freeze an object or refresh old callbacks.
• “let makes callbacks synchronous.” let fixes the binding identity, not the timer schedule.
• “Garbage collection frees anything I am not using mentally.” It frees unreachable values. A closure, listener, timer, or cache can keep a path alive.

Key takeaways

• var in a loop gives callbacks one shared binding; let in the loop header gives each iteration its own binding.
• setTimeout callbacks run later, after the current loop or function has finished.
• A stale closure reads an old binding or object that your current code no longer updates.
• Long-lived closures can keep values reachable; copy only what you need and clean up timers and listeners.

A closure pitfall is a correct memory of the wrong thing: the wrong binding, the wrong time, or a value that should no longer be kept alive.

Up next: The old var & the global object.