JavaScript Garbage Collection

Garbage collection automatically reclaims memory occupied by JavaScript objects that are no longer reachable by the running program. For frontend engineers, understanding reachability, references, and memory leaks helps explain why some applications grow in memory over time.

JavaScript uses automatic memory management, so developers normally do not explicitly free objects. The engine allocates memory when values and objects are created and later determines which allocated objects can still be reached by the program.

A common way to understand garbage collection is reachability. Objects that can be reached from roots such as active execution contexts and global references are considered reachable. An object that is no longer reachable can eventually be reclaimed, although the exact timing and collection strategy are implementation details of the JavaScript engine.

Memory leaks can still occur in garbage-collected JavaScript. A value is not collectible merely because the application no longer needs it; if something still holds a reference to it, the garbage collector generally treats it as reachable. Common causes include accidentally retained event listeners, timers, global data, detached DOM-related references, and growing caches.

Garbage collection has a performance cost because the engine must do work to identify and reclaim memory. Modern engines use generational and incremental techniques, among others, to reduce pauses and improve responsiveness. Frontend developers should therefore focus less on manually forcing collection and more on avoiding unnecessary long-lived references.

Key points

Interview questions

What is garbage collection in JavaScript?

Garbage collection is the JavaScript engine's automatic process for reclaiming memory that is no longer needed by reachable program state. The engine identifies objects that cannot be reached from its relevant roots and can reclaim their storage. Developers therefore usually do not explicitly free ordinary JavaScript objects. The timing and implementation of collection depend on the engine.

When does an object become eligible for garbage collection?

An object becomes eligible when there is no remaining path from the program's live roots to that object. For example, if a variable is the only reference to an object and that variable is reassigned, the object may become unreachable. Eligibility does not mean the engine immediately collects it. The collector chooses when and how to perform the actual reclamation.

How can a frontend application leak memory despite garbage collection?

Garbage collection cannot reclaim an object while a live reference still leads to it. A frontend application can therefore retain objects accidentally through long-lived event listeners, timers, global variables, or caches that grow without bounds. Detached DOM-related structures can also remain in memory when application code retains references to them. The practical fix is to identify and remove unnecessary references rather than trying to manually trigger collection.

Does setting a variable to null immediately free the object's memory?

No. It only removes that particular reference. If another reachable reference still points to the object, the object remains reachable and cannot be reclaimed. Even when the object becomes unreachable, garbage collection happens according to the engine's scheduling and collection strategy rather than immediately.

Why should frontend engineers care about garbage-collection behavior?

Garbage collection affects both memory usage and runtime performance. Excessive allocation can create more work for the engine, while retained objects can cause memory usage to grow over time. Long or poorly timed collection work can also contribute to responsiveness problems. Understanding allocation and retention helps developers design components, caches, and event handling that release resources appropriately.