How JavaScript does Memory Management and Garbage Collection

Every piece of data your program uses goes through three phases. Allocation is when memory is reserved for a value. Usage is when the program reads from or writes to that memory. Release is when the memory is freed and made available for future allocations. In low-level languages, developers manage all three phases manually. In JavaScript, allocation and release are handled automatically, though understanding them is essential for avoiding memory leaks.

JavaScript allocates memory automatically when you declare variables, create objects, define functions, or create arrays. Primitives like numbers and booleans are stored in the stack, a fixed-size region of memory accessed in Last In First Out order. Objects and arrays are stored in the heap, a larger, dynamic region of memory. The stack is managed automatically by the engine. The heap requires garbage collection to reclaim unused memory.

The JavaScript garbage collector uses reachability as its criterion for deciding what memory to free. A value is reachable if it can be accessed from any root. Roots include global variables, the current call stack, and closure variables. If an object can be reached by following any chain of references from a root, it is alive and its memory is retained. If an object has no path from any root to it, it is unreachable and eligible for collection.

Modern JavaScript engines use the mark-and-sweep algorithm for garbage collection. The collector starts from all roots and marks every object it can reach by following references. After marking all reachable objects, it sweeps through the heap and frees the memory of every object that was not marked. This algorithm correctly handles circular references, which was a problem for older reference-counting approaches.

Variables declared in the global scope or accidentally created without a declaration keyword are never garbage collected because they are always reachable from the global root. If you accumulate data in global variables without ever clearing it, such as pushing to a global array indefinitely, the memory grows without bound. Use let and const in local scopes, avoid global variables for data accumulation, and explicitly null out global references when no longer needed.

When you add an event listener to a DOM element, the listener callback holds a reference to everything in its closure. If the element is removed from the DOM but the event listener is never removed, the garbage collector cannot collect the element or anything the callback references. Always call removeEventListener before removing elements. Use AbortController to cancel multiple listeners at once, or use the once option to automatically remove a listener after it fires.

A detached DOM node is an element that has been removed from the document but is still referenced by JavaScript variables or data structures. The garbage collector cannot collect it because the JavaScript reference keeps it alive. This is common when you store DOM elements in arrays or Maps and then remove those elements from the page without clearing the references. Set the JavaScript references to null when removing elements from the page.

Browser DevTools provide a Memory panel for diagnosing memory issues. Take a heap snapshot to see all objects currently in memory and their sizes. Use the Allocation instrumentation on timeline to record memory allocations over time and identify which code paths are allocating unexpectedly. Take multiple snapshots and compare them to find objects that accumulate between snapshots. Look for growing Arrays, Maps, or detached DOM trees as the most common sources of leaks.