Memory management

What it is and why it exists

JavaScript memory management covers allocating storage for values, accessing those values during execution, and reclaiming storage that is no longer needed. The runtime handles the last step through garbage collection , so application code has no general-purpose free() operation. Automatic reclamation prevents many dangling-pointer failures, but it doesn’t understand your business lifecycle.

A collector cares about reachability , not whether an object “looks unused.” As long as the runtime can follow strong references from a root to an object, it must retain that object and the reachable part of its object graph . Globals, bindings in active execution, and callbacks held by a host can all participate in such paths.

In a garbage-collected language, a memory leak usually doesn’t mean unreachable objects failed to be freed. It means objects the application no longer needs remain reachable. An ever-growing Map, an event listener that was never removed, or a long-lived closure capturing a large object are common sources; the collector cannot infer that those references violate product intent.

You meet memory problems in long-lived pages, Node.js services, caches, subscription systems, and allocation-heavy workloads. The right goal isn’t to assign null to every local as soon as possible; it is to make data ownership, capacity limits, and cleanup timing visible. Optimize for garbage collection only after measurement shows that allocation rate or pauses are a real problem.

How it works

Think of runtime memory as a directed graph: objects are nodes, while properties, collection entries, and closure captures are edges. A collector begins from a set of roots and marks the nodes it can reach; only the unmarked part is eligible for reclamation. ECMAScript doesn’t require every engine to use one specific algorithm, so mark-and-sweep is a useful mental model rather than a guarantee of every implementation detail.

The X → Y → X cycle has no path from a root, so the cycle alone doesn’t stop a modern tracing collector from reclaiming it. By contrast, the host still stores Registered callback, so its Captured state remains reachable. When investigating a problem, find the retaining path from a root to the target instead of merely counting references between objects.

Strong references and lifetimes

Ordinary variables, object properties, array elements, and Map keys and values normally form strong references. Removing one edge makes a target unreachable only if it was the last path from any root; assigning null to one local does not remove aliases. Collection timing is also outside application control, so becoming unreachable and actually being reclaimed are separate events.

Leaving a scope often removes a path, but “the stack is cleared and the object is collected when scope exits” is too implementation-specific. An engine can represent values in registers, stacks, or heaps as long as observable behavior is correct. For leak analysis, reasoning about bindings and object graphs is more reliable than guessing whether a value lives on “the stack or heap.”

Weak collections and weak references

Keys in WeakMap and members of WeakSet do not remain alive solely because they are in that collection, provided they are garbage-collectable objects or non-registered symbols. They fit metadata whose keys have owners elsewhere. A weak collection is not enumerable and has no size, because exposing a current entry list would make unpredictable garbage-collection timing observable to the program.

WeakRef provides weak access to a target, and deref() may return the object or undefined. Code must not treat the target’s continued existence as a business guarantee, even when calls are close together. Prefer an ordinary reference whenever it expresses ownership; weak references primarily serve measured, specialized caches or bridge structures where entries may disappear at any time.

FinalizationRegistry can arrange a callback after a target is collected, but that callback may run much later or never run. It cannot own correctness duties such as closing a file, committing a transaction, or releasing a lock. External resources need an explicit close(), dispose(), or structured lifetime; a finalizer is at most a fallback or diagnostic signal.

Collection versus resource cleanup

Memory reclamation answers when storage can be reused. Resource cleanup answers when a listener, timer, socket, or file handle should stop operating. They are related, but they do not share a clock: a reachable component can close a socket correctly, while an unreachable wrapper might never get a finalizer callback.

Owners should therefore detach external registrations and delete unneeded collection entries when their lifecycle ends. Cleanup methods should ideally be safe to call more than once and safe after partial initialization. This shortens retaining paths and makes behavior independent of garbage-collector scheduling.

Examples

The four examples progress through strong collection retention, listener cleanup, a bounded cache, and a weak association. Every output shown was produced with local Node 24. None forces garbage collection because collection timing is not a portable program contract.

Finding the real strong reference

After the local job is assigned null, the Map still stores the job object as a value. Deleting the mapping removes the long-lived strong-reference path shown here.

job = null changes only the local binding; it does not walk the program and clear every alias. activeJobs.delete(jobId) removes the Map edge, but the example cannot prove immediate collection because the engine may run GC later. The object remains alive if another strong reference exists.

This is also the basic method for diagnosing retention: identify the target object, then follow its retaining paths back to roots. Seeing one null assignment doesn’t end the investigation. You must also inspect collections, closures, DOM properties, and host registrations for remaining paths.

Ending a listener lifetime with one signal

AbortController lets several listeners in one lifecycle share an explicit stop signal. After abort(), the second dispatch no longer invokes the handler, so this registration path no longer retains the handler’s captured prices array.

const feed = new EventTarget();
const controller = new AbortController();
const prices = [];

feed.addEventListener(
  "price",
  (event) => prices.push(event.value),
  { signal: controller.signal },
);

const firstUpdate = new Event("price");
firstUpdate.value = 101;
feed.dispatchEvent(firstUpdate);
console.log(prices);

controller.abort();

const lateUpdate = new Event("price");
lateUpdate.value = 102;
feed.dispatchEvent(lateUpdate);
console.log(prices);

[ 101 ]
[ 101 ]

This pattern gives the lifecycle owner a cleanup handle instead of requiring a caller to reconstruct the same anonymous function for removeEventListener(). In a UI component, the controller usually belongs to the component instance and aborts during unmount. If one controller manages several registrations, verify that they really share a lifetime.

Aborting the listener does not empty prices; that isn’t the listener API’s responsibility. Whether the array can be collected depends on its remaining references, and it should remain if the component still displays history. Memory management is about expressing ownership, not mechanically assigning null to every field.

Putting a hard bound on a strong cache

A strong-reference cache needs a capacity, expiration, or explicit invalidation policy. This small cache deletes the earliest key by insertion order, so no more than two values remain after the third insertion.

class RecentCache {
  #entries = new Map();

  constructor(limit) {
    if (!Number.isInteger(limit) || limit < 1) {
      throw new RangeError("limit must be a positive integer");
    }
    this.limit = limit;
  }

  set(key, value) {
    this.#entries.delete(key);
    this.#entries.set(key, value);

    if (this.#entries.size > this.limit) {
      const oldestKey = this.#entries.keys().next().value;
      this.#entries.delete(oldestKey);
    }
  }

  keys() {
    return [...this.#entries.keys()];
  }
}

const cache = new RecentCache(2);
cache.set("profile:1", { name: "Ada" });
cache.set("profile:2", { name: "Lin" });
cache.set("profile:3", { name: "Sam" });

console.log(cache.keys());
console.log(cache.limit);

[ 'profile:2', 'profile:3' ]
2

This is an insertion-order cache, not a complete LRU: reading an entry does not refresh its position. The name should state that contract so callers don’t assume hot entries remain. A production implementation must also define overwrite, concurrent load, failure-result, and time-expiration semantics.

The bound separates worst-case entry count from input size, but an entry count is not a byte count. If values differ greatly in size, use a weight limit or measure actual retained size under load. Without a measurement, don’t claim that an object pool or handwritten loop necessarily uses less memory.

Associating non-owning metadata with WeakMap

WeakMap lets the session object determine the metadata entry’s lifetime. A structurally identical new object is not the original key, while an alias remains a strong reference, so metadata stays readable through alias after assigning null to session.

const access = new WeakMap();

let session = { id: "s-1" };
const alias = session;
access.set(session, { role: "admin" });

console.log(access.get(session).role);
console.log(access.has({ id: "s-1" }));

session = null;
console.log(access.get(alias).role);
console.log(typeof access.keys);

admin
false
admin
undefined

The last line shows that WeakMap has no keys() method. Code cannot enumerate current entries or use an example to observe exactly when a target is collected. If a cache must be enumerable, measurable, or queried by string keys, use a bounded Map rather than switching to a weak collection for “automatic cleanup.”

A weak collection does not weaken references elsewhere in the program. alias still retains the session, so its metadata remains available. When reviewing a weak cache, inspect who strongly owns each key and whether a value unnecessarily retains a larger object graph.

Pitfalls

Treating a cycle as a leak

Fix: inspect the retaining path from a root to the object in a heap snapshot. If it goes through a global collection, active listener, or unfinished task, fix that long-lived edge. Don’t scatter null assignments merely to break an already unreachable internal cycle.

Letting a cache grow without a bound

Fix: specify the cache owner, maximum entry count or weight, eviction rule, and invalidation trigger. Test overflow, overwrites, and failed loads, then observe whether retained size reaches a plateau under steady load.

Registering without symmetric cleanup

Fix: make registration return a cleanup function, or use an owner-held AbortSignal. Run cleanup on unmount, cancellation, and partial-initialization failure; test repeated mount/unmount cycles using listener counts or heap snapshots.

Treating WeakRef as a reliable cache

Fix: treat a weak-cache hit as an optional optimization and make every miss recoverable from computation or authoritative storage. Use a strong cache with an explicit eviction policy when you need stable capacity, hit-rate metrics, or iteration.

Depending on FinalizationRegistry for resources

Fix: expose an explicit, idempotent close operation and ensure it runs with try/finally or a structured API. A finalizer may report omissions or provide non-critical fallback work, but it isn’t the primary lifecycle protocol.

Declaring a leak after one heap increase

Fix: hold input and idle state constant, repeat one operation for several rounds, take snapshots at comparable collection points, and compare object counts and retaining paths. Treat growth as leak evidence only when it fails to plateau and the growing objects match a lifecycle suspicion.

Further reading

• MDN: Memory management covers reachability, garbage collection, and the basic model of leaks.
• MDN: WeakMap documents weak keys, non-enumerability, and intended uses.
• MDN: WeakRef explains deref() and why weak references should usually be avoided.
• MDN: FinalizationRegistry defines the nondeterministic finalization guarantees.
• V8: Trash talk describes Orinoco’s generational, parallel, and concurrent collection design.
• Chrome DevTools: Fix memory problems presents a browser workflow for heap snapshots and retaining trees.