原生JavaScript内存泄漏的常见场景、具体成因、代码示例及正确内存释放方案

Hey there! Let's dive into the most common memory leak scenarios in vanilla JavaScript, why they occur, and how to fix them with practical code examples. Memory leaks are sneaky—they build up over time and can slow down your app or even cause crashes, so spotting them early is key.

1. Accidental Global Variables #

Why it leaks: #

In non-strict mode, JavaScript automatically hoists undeclared variables to the global scope (like window in browsers or global in Node.js). Global variables are never garbage-collected as long as the page/process is running, so they hang around taking up memory indefinitely.

Leaky code example: #

function processData() {
  // Oops! Forgot to declare 'userData' with let/const/var
  userData = { name: "Alice", data: new Array(100000).fill("stuff") };
  console.log(userData.name);
}

processData();
// 'userData' is now a global variable, never cleaned up

Fixed code: #

Use strict mode to catch undeclared variables, and always declare your variables properly. If you do need a global variable, explicitly assign it to window (in browsers) and delete it when done:

'use strict'; // Enforces strict mode, throws error for undeclared variables

function processData() {
  const userData = { name: "Alice", data: new Array(100000).fill("stuff") };
  console.log(userData.name);
}

processData();
// userData is scoped to the function, gets GC'd after execution

// If you must use a global:
window.tempGlobal = "something";
// When no longer needed:
delete window.tempGlobal;

2. Uncontrolled Closures #

Why it leaks: #

Closures retain references to variables from their outer scope, even after the outer function has finished executing. If the closure itself is kept alive (e.g., stored in a global variable), those outer variables can't be garbage-collected.

Leaky code example: #

function createUserTracker() {
  const userSession = { id: "abc123", activity: new Array(5000).fill("click") };
  
  // Return a closure that references userSession
  return function() {
    console.log(`Session ID: ${userSession.id}`);
  };
}

// Store the closure globally—userSession is now forever held in memory
const permanentTracker = createUserTracker();

Fixed code: #

If you no longer need the closure, nullify its reference to let the garbage collector clean up the outer variables:

function createUserTracker() {
  const userSession = { id: "abc123", activity: new Array(5000).fill("click") };
  
  return function() {
    console.log(`Session ID: ${userSession.id}`);
  };
}

let temporaryTracker = createUserTracker();
// Use the closure...
temporaryTracker();

// When done, nullify the closure reference
temporaryTracker = null;
// Now userSession can be garbage-collected

3. Uncleaned DOM Element References #

Why it leaks: #

If your JavaScript holds a reference to a DOM element that's been removed from the DOM tree, the garbage collector can't reclaim that element's memory—because there's still a live reference to it in your code.

Leaky code example: #

const modal = document.getElementById("popup-modal");
const closeBtn = modal.querySelector(".close");

closeBtn.addEventListener("click", () => {
  // Remove modal from DOM, but keep the 'modal' variable reference
  document.body.removeChild(modal);
});

// Even after removal, 'modal' still points to the element—memory isn't freed

Fixed code: #

After removing the element from the DOM, explicitly nullify your JavaScript reference to it:

let modal = document.getElementById("popup-modal");
const closeBtn = modal.querySelector(".close");

closeBtn.addEventListener("click", () => {
  document.body.removeChild(modal);
  // Nullify the reference to let GC clean up the element
  modal = null;
});

Bonus: For elements with event listeners, always remove the listener before deleting the element to avoid additional leaks.

4. Forgotten Timers & Event Listeners #

Why it leaks: #

setInterval, setTimeout, and event listeners hold references to their callback functions. If you don't clean them up when they're no longer needed (e.g., when a component unmounts or the page navigates), the callbacks and any variables they reference will stay in memory.

Leaky code example (Timer): #

function startDataPoller() {
  const largeDataset = new Array(100000).fill("sensor-data");
  
  // This interval runs forever, holding a reference to largeDataset
  setInterval(() => {
    console.log("Polling data:", largeDataset[0]);
  }, 1000);
}

startDataPoller();

Fixed code (Timer): #

Store the timer ID and clear it when done:

function startDataPoller() {
  const largeDataset = new Array(100000).fill("sensor-data");
  const pollerId = setInterval(() => {
    console.log("Polling data:", largeDataset[0]);
  }, 1000);
  
  // Return the ID so we can clear it later
  return pollerId;
}

const poller = startDataPoller();

// When you need to stop polling:
clearInterval(poller);

Leaky code example (Event Listener): #

const button = document.getElementById("action-btn");

// Anonymous function can't be removed later!
button.addEventListener("click", () => {
  console.log("Button clicked");
});

// Even if button is removed from DOM, the listener remains in memory

Fixed code (Event Listener): #

Use a named function so you can explicitly remove the listener:

const button = document.getElementById("action-btn");

function handleClick() {
  console.log("Button clicked");
}

button.addEventListener("click", handleClick);

// When done (e.g., before removing the button):
button.removeEventListener("click", handleClick);

5. Unbounded Caching #

Why it leaks: #

Using a plain object or Map as a cache without any cleanup logic means data keeps piling up indefinitely. Over time, this can consume massive amounts of memory.

Leaky code example: #

const cache = {};

function cacheResult(key, value) {
  cache[key] = value; // Never removes old entries
}

// Add 1000s of entries to the cache
for (let i = 0; i < 10000; i++) {
  cacheResult(`key-${i}`, new Array(1000).fill("data"));
}

Fixed code: #

Use a WeakMap (for object keys, since it uses weak references) or implement an expiration/eviction policy:

// Option 1: Use WeakMap (keys must be objects)
const cache = new WeakMap();
const objKey = { id: "user123" };

cache.set(objKey, { name: "Bob", data: [...] });
// When objKey is nullified, the cache entry is automatically cleaned up
objKey = null;

// Option 2: Implement a size-limited cache
const cache = new Map();
const MAX_CACHE_SIZE = 100;

function cacheResult(key, value) {
  if (cache.size >= MAX_CACHE_SIZE) {
    // Delete the oldest entry
    const firstKey = cache.keys().next().value;
    cache.delete(firstKey);
  }
  cache.set(key, value);
}

6. Console Logs (Dev Environment Trap) #

Why it leaks: #

When you log objects to the browser console, the console keeps a reference to those objects. Even if your code no longer uses the object, the console's reference prevents garbage collection. This is mostly a dev issue, but it can throw off memory profiling.

Leaky code example: #

const hugeObject = new Array(1000000).fill("dev-test-data");
console.log(hugeObject); // hugeObject is now held by the console

Fixed code: #

Remove console logs in production, or avoid logging large objects during development if you're testing memory usage:

// In production, use a logger that strips console logs, or manually remove them
const hugeObject = new Array(1000000).fill("dev-test-data");
// console.log(hugeObject); // Comment out or remove in prod

内容的提问来源于stack exchange，提问作者King是太阳