JavaScript's garbage collection (GC) automatically manages memory through the tag-cleaning mechanism, marks accessible objects from the root object, and clears unreachable objects to free up memory; common memory leaks include unexpected global variables, uncleared event listeners and timers, nodes that are separated from the DOM but are still referenced, and closures retain large object references; modern engines use generational recycling, incremental and concurrent recycling to optimize performance; developers can assist GC by manually emptying references, clearing event listening, avoiding long-life cycle closures, and using WeakMap/WeakSet.

JavaScript's garbage collection (GC) is a behind-the-scenes mechanism that automatically manages memory by cleaning up objects no longer needed by your program. Most developers don't need to think about it daily, but understanding how it works helps you write more efficient code and avoid memory leaks.

How Garbage Collection Works: The Basics

JavaScript engines (like V8 in Chrome and Node.js) use automatic memory management . When you create objects, arrays, or functions, memory is allocated. When those values are no longer reachable or usable, the garbage collector steps in and frees up that memory.

The core idea is reachability :

• The garbage collector starts from a set of “root” objects (like global variables and currently executing function variables).
• It then traces all objects that can be reached from these roots through references.
• Anything that can't be reached is considered garbage and is eligible for cleanup.

This approach is known as mark-and-sweep :

1. Mark phase : The GC walks through all reachable objects starting from roots and marks them as “alive.”
2. Sweep phase : It goes through memory and deletes everything not marked.

This is more effective than older reference-counting methods, which fail on circular references (eg, a.ref = b; b.ref = a; — neither has zero references, but both may be unreachable from the root).

Common Causes of Memory Leaks in JavaScript

Even with automatic GC, you can still create memory leaks. Here are the most common patterns:

• Accidental global variables

   function badFunc() {
    leaked = "I'm global now"; // Forgot 'var', 'let', or 'const'
  }

  This attaches data to the global object (eg, window ), which is always reachable → never collected.

• Forgotten event listeners or times

   setInterval(() => {
    const hugeData = fetchData();
    // If this never clears, hugeData stays in memory
  }, 1000);

  Timers and DOM event listeners keep references to their closings. If not cleaned up, they prevent cleanup of associated data.

• Detached DOM nodes with retained references

   let node = document.getElementById("tmp");
  document.body.removeChild(node);
  // But we still hold a reference in 'node'

  Even though the node is removed from the DOM, as long as JavaScript holds a reference, it won't be collected.

• Closures that retain large scopes

   function outer() {
    const bigData = new ArrayBuffer(1024 * 1024 * 10); // 10MB
    return function inner() {
      // Even if inner doesn't use bigData, it's in scope
      console.log("Hello");
    };
  }

  inner closes over bigData , so it can't be collected as long as inner exists.

How Modern Engines Optimize GC

JavaScript engines don't run GC constantly — that would slow things down. Instead, they use generational garbage collection and incremental collection :

• Generational collection
  Based on the observation that most objects die young:

  • Memory is split into young and old generations.
  • New objects go into the young generation.
  • Frequent, fast GC runs clean up the young generation (most objects are gone quickly).
  • Objects that survive multiple young GCs are promoted to the old generation.
  • Old generation is cleaned less frequently.

• Incremental and concurrent GC
  To avoid freezing the app, modern GCs:

  • Break the mark phase into chunks (incremental).
  • Run some work in parallel or on separate threads (concurrent).
  • Minimize pauses so your app stays responsive.

This means GC is not just “stop the world” — it's highly optimized for real-world performance.

Tips to Help the Garbage Collector

You can't force GC, but you can help it:

• Null out references when you're truly done with large objects:

   let data = { /* big object */ };
  // ... use data
  data = null; // Makes it eligible for collection

• Clean up event listeners :

   const handler = () => { /* ... */ };
  button.addEventListener("click", handler);
  // Later:
  button.removeEventListener("click", handler);

• Avoid long-lived closes over large data.

• Use weak collections when appropriate:

  • WeakMap and WeakSet hold references weakly — they don't prevent GC.
  • Useful for metadata or caches tied to objects that should disappear when the object does.

Basically, JavaScript's garbage collector is smart and efficient, but it can't read your mind. If you keep references to things you no longer need, they won't be cleaned up. Understanding reachability and common leak patterns go a long way in writing stable, memory-efficient apps.

The above is the detailed content of How JavaScript's Garbage Collection Really Works. For more information, please follow other related articles on the PHP Chinese website!