Engineer Leak-Free JavaScript: Mastering Memory Management
Activate your mastery over JavaScript's hidden memory challenges. We embark on a surgical exploration to diagnose and neutralize common memory leaks that undermine application performance and stability. Unchecked, these silent resource drains can transform robust software into sluggish, unresponsive systems. This guide empowers us to identify insidious issues like detached DOM nodes, forgotten timers, and persistent global variables that evade JavaScript's sophisticated garbage collection mechanisms.
We will forge a profound understanding of how memory operates within the browser environment, exposing the vulnerabilities that lead to accumulation. This detailed expedition provides actionable strategies and code examples, transforming abstract concepts into tangible fixes. Prepare to refine your development pipeline and elevate your applications. Our journey to engineering high-performance, resilient JavaScript is critical for any developer committed to building scalable solutions and to advance our collective skills in implementing professional software design patterns in JavaScript.
Deconstruct JavaScript Memory Management: The Foundation for Leak Prevention
To conquer JavaScript memory leaks, we first decode the engine's core memory management architecture. The V8 engine, powering Chrome and Node.js, meticulously allocates memory for our applications. It partitions memory into two primary regions: the Stack, for static data like function calls and primitive values, and the Heap, a dynamic region for objects, arrays, and closures. JavaScript employs a sophisticated Garbage Collector (GC), a background process designed to reclaim memory occupied by objects no longer referenced by the active parts of our program. This automated process, often relying on a 'mark-and-sweep' algorithm, identifies unreachable objects and deallocates their memory.
However, the GC is not omniscient. It operates on the principle of reachability. If an object, though no longer functionally needed, remains indirectly referenced by an active part of the program, the GC perceives it as 'reachable' and will not reclaim its memory. This fundamental misunderstanding fuels the genesis of memory leaks. Our mission is to activate a system thinking approach, anticipating scenarios where references persist longer than intended. We proactively design our code to facilitate efficient garbage collection, preventing silent resource depletion that degrades user experience and system stability.
The impact of memory leaks extends beyond mere performance degradation. They amplify resource consumption, leading to browser crashes, frozen user interfaces, and even device overheating on resource-constrained platforms. As applications grow in complexity and usage duration, even minor leaks can accumulate into significant issues. Our strategic objective is to identify these silent saboteurs and engineer robust solutions. We will explore specific patterns that lead to leaks and forge practical methods to eliminate them, ensuring our JavaScript applications run with surgical precision and optimal resource allocation.
// No specific code for this foundational explanation, focuses on concepts.Neutralizing Detached DOM Node Leaks
Detached DOM node leaks represent a critical vulnerability where JavaScript maintains a reference to a DOM element that has been removed from the document tree. While the element is no longer visible or interactive, its existence in memory persists, along with any data or event listeners attached to it. This scenario frequently emerges in dynamic web applications that extensively manipulate the DOM, such as single-page applications (SPAs) or frameworks that manage component lifecycles. We observe this when an element is removed using methods like removeChild() or innerHTML = '', yet an active JavaScript variable or, more commonly, an event listener, continues to point to that element.
To illustrate, imagine a modal dialog with several buttons. When the modal closes, we might simply remove its root element from the DOM. However, if any of those buttons had event listeners attached and stored in variables, or if the modal itself was referenced by a long-lived closure, the browser's garbage collector cannot reclaim the memory associated with the entire modal's subtree. The element, though 'detached', remains 'reachable' through the JavaScript reference. This leads to a creeping accumulation of unused DOM structures and associated data, which directly translates to increased memory footprint and degraded application responsiveness.
We engineer the fix by systematically breaking these persistent references. The primary strategy involves explicitly calling removeEventListener() for every event listener that was previously attached to a DOM node before its removal. Furthermore, we must nullify any JavaScript variables that hold direct or indirect references to the detached DOM element. This proactive dereferencing ensures that when an element is functionally removed, its memory becomes truly eligible for garbage collection. Implement a robust cleanup mechanism, often integrated into component unmount or destruction phases, to guarantee that no dangling references remain. We prioritize explicit deallocation of resources, preventing silent memory retention.
Consider scenarios where complex component trees are rendered and unmounted. Each component must implement a lifecycle hook or a dedicated cleanup function that meticulously removes event listeners, clears timers, and nullifies references to internal DOM elements and data. This surgical approach eliminates ambiguity for the garbage collector, allowing it to efficiently reclaim memory. Ignoring this critical step transforms dynamic DOM manipulation into a fertile ground for memory leaks. We activate this disciplined approach to ensure our applications maintain optimal memory profiles, even under continuous, heavy usage. This strategic imperative secures the long-term performance and stability of our JavaScript architectures.
/*
* Scenario: Detached DOM Node Leak
* A common leak occurs when DOM elements are removed from the document
* but their references (especially event listeners) are still held by JavaScript.
* The browser cannot garbage collect the DOM node or its subtree if there are active JS references.
*/
// 1. Setup: Create a container and a button that will be removed
const container = document.createElement('div');
document.body.appendChild(container);
function createLeakyElement() {
const leakyButton = document.createElement('button');
leakyButton.textContent = 'Leaky Button';
container.appendChild(leakyButton);
// PROBLEM: Attach an event listener that references the button or its scope
// If 'heavyData' was large, it would also be leaked.
const heavyData = Array(100000).fill('some-heavy-string'); // Simulating heavy data
const clickHandler = () => {
console.log('Button clicked', heavyData.length);
};
leakyButton.addEventListener('click', clickHandler);
// Return the handler for demonstration of correct cleanup
return { leakyButton, clickHandler };
}
let { leakyButton, clickHandler } = createLeakyElement();
// Simulate removing the element from the DOM without cleanup
console.log('--- Simulating Leak ---');
if (leakyButton && leakyButton.parentNode) {
leakyButton.parentNode.removeChild(leakyButton);
console.log('Leaky button removed from DOM. Reference still held by `leakyButton` variable and its event listener.');
}
// At this point, `leakyButton` and `clickHandler` still hold references.
// The DOM node and `heavyData` CANNOT be garbage collected.
// To fix, we must explicitly nullify references AND remove event listeners.
console.log('\n--- Implementing Fix ---');
// FIX: Ensure all references are nullified and event listeners removed.
// This often needs to happen when a component unmounts or is destroyed.
const fixedContainer = document.createElement('div');
document.body.appendChild(fixedContainer);
function createCleanElement() {
const cleanButton = document.createElement('button');
cleanButton.textContent = 'Clean Button';
fixedContainer.appendChild(cleanButton);
const heavyData = Array(100000).fill('some-heavy-string');
const clickHandler = () => {
console.log('Clean button clicked', heavyData.length);
};
cleanButton.addEventListener('click', clickHandler);
return { cleanButton, clickHandler };
}
let { cleanButton, clickHandler: cleanClickHandler } = createCleanElement();
// Simulate component unmount/destruction with proper cleanup
console.log('Removing clean button from DOM with cleanup...');
if (cleanButton && cleanButton.parentNode) {
// STEP 1: Remove the event listener BEFORE removing the element
cleanButton.removeEventListener('click', cleanClickHandler);
console.log('Event listener removed.');
// STEP 2: Remove the element from the DOM
cleanButton.parentNode.removeChild(cleanButton);
console.log('Clean button removed from DOM.');
}
// STEP 3: Nullify external references to the element and handler
cleanButton = null;
cleanClickHandler = null;
console.log('External references nullified. Element and associated data are now eligible for GC.');
// Clean up the containers themselves for a complete example
document.body.removeChild(container);
document.body.removeChild(fixedContainer);
/*
* Observe the difference:
* In the 'leaky' scenario, `leakyButton` and `clickHandler` prevent GC.
* In the 'fixed' scenario, after cleanup, the button, its data, and handler are all dereferenced,
* making them eligible for garbage collection.
*/Disarming Forgotten Timers and Rogue Callbacks
Forgotten timers and rogue callbacks represent another significant vector for JavaScript memory leaks. Functions like setInterval() and setTimeout() are powerful tools for managing asynchronous operations, but their improper use can lead to persistent references that thwart the garbage collector. When we activate a timer, the callback function supplied to it remains active until the timer is explicitly cleared using clearInterval() or clearTimeout(). If this cleanup step is overlooked, particularly when the component or context that initiated the timer is conceptually 'destroyed' or navigates away, the callback (and any variables it closes over) persists in memory indefinitely.
This scenario becomes particularly problematic when the callback function forms a closure over a substantial scope, such as a component instance containing large data structures or DOM references. The timer's continuous execution prevents the entire closure, along with its associated data, from being garbage collected. For instance, in a Single Page Application (SPA), navigating from a page that initiated a setInterval without clearing it means the timer continues to run in the background, consuming CPU cycles and, more critically, holding onto all the memory it needs for its execution context. This is a subtle but potent form of memory leak, as the developer might assume the context is gone once the component is unmounted from the DOM.
We forge a proactive defense against these leaks by enforcing strict timer management. Every setInterval or setTimeout initiated must have a corresponding cleanup operation. For components, this typically integrates into a 'destroy' or 'unmount' lifecycle method. This method’s critical function is to explicitly call clearInterval() or clearTimeout() for all active timers. This action immediately liberates the callback function and its closure from memory, allowing the garbage collector to reclaim the associated resources. We activate this discipline to ensure that resources are provisioned only for their active lifetime, preventing dormant processes from accumulating.
Beyond timers, persistent event listeners, especially those attached to global objects like window or document, can also act as rogue callbacks. If an event listener is added but never removed when the component that added it is destroyed, it creates a persistent closure. This closure holds a reference to the component, preventing its garbage collection. We optimize our development practices by always pairing addEventListener() with removeEventListener() in corresponding lifecycle phases. This systematic approach ensures that our applications remain lean, responsive, and free from the insidious creep of memory accumulation, elevating the overall robustness of our JavaScript ecosystems.
/*
* Scenario: Forgotten Timer Leak
* setInterval and setTimeout create timers that, if not explicitly cleared,
* will continue to execute or hold references, even if the context that created them
* is no longer active or visible. This prevents associated data from being GC'd.
*/
// 1. Setup: A component that uses setInterval
class LeakyComponent {
constructor() {
this.data = Array(100000).fill('leaky-timer-data'); // Simulating heavy data
this.timerId = setInterval(() => {
// This callback holds a reference to 'this' (LeakyComponent instance)
// and therefore to 'this.data'.
// If the component is conceptually destroyed but the timer isn't cleared,
// 'this.data' and the entire component instance are leaked.
console.log('Leaky timer ticking...', this.data.length);
}, 1000);
console.log('LeakyComponent created with timer ID:', this.timerId);
}
// PROBLEM: No explicit method to clear the timer
// If this instance is dereferenced, the timer continues and prevents GC.
}
console.log('--- Simulating Leak ---');
let leakyInstance = new LeakyComponent();
// After some time, imagine the component is 'unmounted' or goes out of scope.
// We try to dereference it, but the timer keeps it alive.
leakyInstance = null; // This won't allow GC if the timer is still active!
console.log('Leaky instance dereferenced, but timer is still active, preventing GC.');
// In a real application, you'd observe memory climbing in dev tools.
// We must manually stop the timer to proceed.
// clearInterval(leakyInstance.timerId); // This would require holding onto the timerId explicitly.
console.log('\n--- Implementing Fix ---');
// FIX: Always implement a cleanup mechanism to clear timers.
class CleanComponent {
constructor() {
this.data = Array(100000).fill('clean-timer-data');
this.timerId = setInterval(() => {
console.log('Clean timer ticking...', this.data.length);
}, 1000);
console.log('CleanComponent created with timer ID:', this.timerId);
}
// Add a cleanup method to explicitly stop the timer.
destroy() {
clearInterval(this.timerId);
console.log('CleanComponent timer ID', this.timerId, 'cleared.');
this.timerId = null; // Nullify the reference as well
this.data = null; // Also nullify heavy data for immediate GC eligibility
}
}
let cleanInstance = new CleanComponent();
// Simulate component unmount after a few seconds
setTimeout(() => {
console.log('Simulating CleanComponent destruction...');
cleanInstance.destroy(); // Crucial cleanup call
cleanInstance = null; // Now the instance is truly dereferenced and eligible for GC
console.log('Clean instance destroyed and dereferenced. Now eligible for GC.');
}, 3000); // Allow it to tick a few times then destroy
/*
* Observe the difference:
* The 'leaky' instance's timer continues indefinitely, holding `this.data` in memory.
* The 'fixed' instance explicitly clears its timer, allowing prompt GC upon dereferencing.
*/Containment Strategies for Global Variable and Closure-Induced Leaks
Global variables and misused closures present sophisticated challenges in memory management, often leading to subtle but significant leaks. An unintended global variable occurs when a variable is assigned a value without being explicitly declared with var, let, or const, particularly outside of 'strict mode' or within `eval()` contexts. These variables attach to the global object (window in browsers, global in Node.js) and persist for the entire lifetime of the application. If these global variables hold references to large objects or data structures, that memory is never reclaimed by the garbage collector, creating a permanent leak.
We decode this vulnerability by activating 'strict mode' at the top of our JavaScript files or modules. This compels explicit variable declarations, preventing accidental globals. For intentional global configurations, we exercise extreme caution, ensuring that any objects assigned globally are minimal in size or are explicitly nullified when their utility expires. We engineer our applications to minimize reliance on the global scope, preferring module-level or local scoping, which naturally facilitates garbage collection once those scopes are exited. This containment strategy is paramount for maintaining a lean memory footprint.
Closures, while a cornerstone of JavaScript's power and flexibility, can also inadvertently cause memory leaks. A closure allows an inner function to retain access to its outer function's scope, even after the outer function has finished executing. If this inner function is then assigned to a long-lived reference – perhaps an element's event handler or a component's state – and its outer scope contains large variables or objects, those large elements will be kept alive in memory by the closure. The problem compounds when the inner function itself does not require access to the entire outer scope, but the closure mechanism retains it all.
To disarm closure-induced leaks, we adopt a surgical approach to scope management. We scrutinize our closures to ensure they capture only the absolute minimum data necessary from their outer environments. When designing components, if a closure holds references to heavy resources, we must implement explicit cleanup mechanisms. This involves dereferencing the inner function from its long-lived holder (e.g., removing it from an array of active callbacks, or nullifying its reference) when the associated component or feature is no longer active. We activate practices like using WeakMaps or WeakSets for storing object references that should not prevent garbage collection, particularly in scenarios involving caching or memoization. This meticulous management of references within closures transforms potential memory traps into efficient, garbage-collectible structures, safeguarding our application's performance.
/*
* Scenario: Global Variable Leak
* Accidentally creating global variables (e.g., in non-strict mode without 'var/let/const')
* or explicitly assigning large objects to global scope causes them to persist for the entire application lifetime.
*/
console.log('--- Simulating Global Variable Leak ---');
// PROBLEM: Accidental global variable in non-strict mode
// If 'use strict' is not at the top, `leakyGlobal` would become a global variable.
function createAccidentalGlobalLeak() {
// In non-strict mode, `leakyGlobal = ...` would create a global variable.
// In strict mode, this would throw a ReferenceError.
leakyGlobal = Array(500000).fill('accidental-global-data'); // large data
console.log('Accidental global variable `leakyGlobal` created (or assigned).');
}
createAccidentalGlobalLeak();
// `leakyGlobal` now exists on `window` (or global in Node.js) and will persist.
// We can manually remove it for demonstration purposes:
// delete window.leakyGlobal; // This might work in browsers, but indicates poor design.
/*
* Scenario: Closure-Induced Leak (Holding Large Outer Scope References)
* Closures retain references to their outer scope. If an inner function (closure)
* is exposed or long-lived, and its outer scope contains large variables,
* those large variables will be leaked even if they are no longer needed by the outer function itself.
*/
console.log('\n--- Simulating Closure Leak ---');
let leakingCollection = [];
function createLeakyClosure() {
const hugeData = Array(1000000).fill('massive-closure-data'); // A very large dataset
const innerFunction = () => {
// This inner function only needs a small part of 'hugeData' or even none,
// but it still maintains a reference to the entire 'hugeData' array via its closure.
console.log('Inner function accessed, huge data length:', hugeData.length);
};
// We push the inner function to a long-lived array, effectively leaking hugeData
leakingCollection.push(innerFunction);
console.log('Leaky closure created and pushed to collection.');
}
createLeakyClosure();
createLeakyClosure(); // Create another one
// Now, `hugeData` from both calls to `createLeakyClosure` is retained due to `leakingCollection`
// holding references to the `innerFunction` closures.
console.log('\n--- Implementing Fixes ---');
// FIX 1: Strict Mode for Global Variables
// Encapsulate code in an IIFE or module to prevent accidental globals.
// Always declare variables with 'const', 'let', or 'var'.
(function() {
'use strict';
// 'cleanGlobal = ...' here would throw an error, preventing accidental globals.
// const cleanScopedVar = Array(1000).fill('clean-scoped-data'); // This is fine
console.log('Inside strict mode block. Accidental globals prevented.');
})();
// FIX 2: Managing Closure Leaks
// Ensure closures only capture what they absolutely need,
// or explicitly nullify references when no longer required.
let cleanCollection = [];
function createCleanClosure() {
const hugeData = Array(1000000).fill('massive-closure-data');
let dataReference = hugeData; // Create a temporary reference for inner function
const innerFunction = () => {
console.log('Clean inner function accessed, data length:', dataReference.length);
};
// Instead of pushing the whole closure, consider if only specific values are needed.
// Or, provide a mechanism to "cleanup" the closure's references.
cleanCollection.push(innerFunction);
// If `hugeData` is truly no longer needed by the outer scope after `innerFunction` is created
// but `innerFunction` itself is long-lived, this specific pattern is tricky.
// A more common fix is ensuring the long-lived `cleanCollection` itself is cleared or components it refers to are dereferenced.
// For demonstration, let's assume `hugeData` could be nullified IF `innerFunction` only used a subset.
// Or, a better pattern for specific use cases is to pass only required parts to the inner function.
dataReference = null; // This does not help if `innerFunction` still closes over `hugeData` directly.
// The most direct way to 'fix' a closure leak is to ensure the OUTER function's scope is eligible for GC
// when its internal components (like `innerFunction`) are no longer needed, by dereferencing `innerFunction` from `cleanCollection`.
console.log('Clean closure created.');
return innerFunction; // Return for explicit management
}
let cleanClosure1 = createCleanClosure();
let cleanClosure2 = createCleanClosure();
// To prevent leaks, ensure `cleanCollection` or its items are managed.
// Example: When the components are destroyed, remove them from `cleanCollection`.
// cleanCollection = []; // This would clear all references, allowing GC.
// Or: cleanCollection.pop(); // Remove individual references.
// We will simulate explicit cleanup for closure references:
console.log('Explicitly clearing leaking collection for GC eligibility...');
leakingCollection = []; // All closures from createLeakyClosure are now dereferenced.
console.log('Leaking collection cleared.');
Advanced Leak Detection and Remediation: Leveraging Developer Tools
Pinpointing and remediating memory leaks demands a rigorous, data-driven approach. We activate browser developer tools as our primary investigative instruments, transforming guesswork into precise diagnostics. The Chrome DevTools Memory tab emerges as an indispensable ally in this quest. It offers powerful profiling capabilities, most notably Heap Snapshots and Allocation Instrumentation on Timeline, empowering us to dissect our application's memory consumption with surgical precision.
To initiate a leak investigation, we commence by taking a baseline Heap Snapshot. This captures a comprehensive view of all JavaScript objects and their memory footprint at a specific moment. Subsequently, we execute the application sequence suspected of causing a leak – for example, repeatedly opening and closing a dynamic component, navigating between views, or triggering data fetches. After performing these actions several times to amplify any leak, we take a second Heap Snapshot. The critical step is then to compare these snapshots. DevTools provides a 'Comparison' view that highlights objects that have increased in count or retained size, making transient leaks stand out from expected memory usage.
When analyzing snapshot comparisons, we prioritize objects categorized as 'Detached HTMLDivElement', 'Detached HTMLLIElement', or similar DOM nodes, as these are strong indicators of detached DOM node leaks. For other persistent objects, we drill into their 'Retainers' tree. This reveals the precise chain of references in our JavaScript code that prevents the garbage collector from reclaiming the object's memory. This forensic analysis guides us directly to the line of code responsible for the unintended retention, allowing for targeted remediation. We engineer this diagnostic loop to systematically identify and neutralize memory accumulation patterns.
Beyond snapshots, Allocation Instrumentation on Timeline offers real-time insight into memory allocations. By recording an allocation profile while interacting with the application, we can visualize memory usage spikes and drops. This is particularly effective for identifying short-lived but frequent allocations that might impact performance. The timeline allows us to pinpoint exactly when memory is allocated and, crucially, to examine the call stack responsible for those allocations. This capability empowers us to optimize our code for fewer allocations, enhancing overall memory efficiency. We foster a culture of continuous profiling, integrating these tools into our development workflow to proactively forge leak-free, high-performance JavaScript applications. This systematic exploration ensures our applications remain at the cutting edge of efficiency and reliability.
/*
* No specific executable code for this section. This part focuses on methodology and tool usage.
* The core idea is to explain how to use browser developer tools to profile and find leaks.
*
* Example steps (conceptual, not executable code):
*
* 1. Open Chrome DevTools (F12).
* 2. Navigate to the 'Memory' tab.
* 3. Select 'Heap snapshot' and click 'Take snapshot'.
* - This captures the memory state at a given moment.
* 4. Perform actions in your application that you suspect might cause a leak (e.g., open/close a modal repeatedly, navigate between pages).
* 5. Take another 'Heap snapshot'.
* 6. Compare the two snapshots using the 'Comparison' view.
* - Look for objects with increasing 'Retained Size' or 'Delta' over time.
* - Pay attention to 'Detached HTMLDivElement', 'Detached HTMLLIElement' etc. in the object types.
* - Investigate the 'Retainers' section for these leaked objects to trace back their references in the JavaScript code.
*
* 7. Alternatively, use 'Allocation instrumentation on timeline' for real-time allocation tracking.
* - Start recording.
* - Perform actions.
* - Stop recording and analyze the graph for memory spikes that don't recede.
* - Zoom into problematic areas and examine the call stack to identify the code responsible for allocations.
*
* This methodology guides the developer in pinpointing the exact source of memory growth.
*/Key Takeaways
Understanding JavaScript Memory Mechanics
JavaScript engines (like V8) manage memory via the Heap and Stack, with an automatic Garbage Collector (GC). Leaks occur when the GC cannot identify objects as 'unreachable' due to lingering JavaScript references, even if the objects are no longer functionally required. Master this fundamental concept to preemptively design leak-free applications.
Neutralizing Detached DOM Node Leaks
When DOM elements are removed from the document tree but JavaScript still holds references (especially through event listeners), they become 'detached' and leak memory. Fix: Always call removeEventListener() and nullify all JS references to the element and its children upon removal or component unmount. This ensures the element and its subtree are eligible for GC.
Disarming Forgotten Timers and Rogue Callbacks
setInterval() and setTimeout() callbacks persist in memory until explicitly cleared. If a component using a timer unmounts without calling clearInterval() or clearTimeout(), the timer's callback and its closure (including large outer scope variables) will leak. Fix: Implement robust cleanup methods in component lifecycles to always clear timers and remove global event listeners when components are destroyed.
Containing Global Variable and Closure-Induced Leaks
Accidental global variables (without var/let/const) and closures holding onto unnecessarily large outer scope references cause persistent leaks. Fix: Activate 'strict mode' to prevent accidental globals. For closures, ensure they capture only essential data. Proactively nullify references to large objects held by long-lived closures or ensure the long-lived holders (e.g., arrays of functions) are themselves managed and cleared.
Leveraging Developer Tools for Leak Detection
Chrome DevTools Memory tab is indispensable. Use Heap Snapshots to compare memory states before and after suspected leak-inducing actions, identifying objects with increased retained size. Utilize Allocation Instrumentation on Timeline for real-time memory allocation tracking. Master these tools to surgically pinpoint and remediate leak sources.
FAQ
-
What is the primary cause of JavaScript memory leaks despite automatic garbage collection?
The primary cause of JavaScript memory leaks is the persistence of 'reachable' but unused references. While JavaScript's Garbage Collector (GC) automatically reclaims memory for objects no longer referenced by the program, leaks occur when active parts of the code inadvertently hold onto references to objects that are no longer functionally needed. This prevents the GC from identifying them as 'unreachable' and thus from freeing up their memory.
-
How can I prevent detached DOM node memory leaks?
To prevent detached DOM node leaks, always ensure that when you remove a DOM element from the document, you also explicitly remove all associated event listeners using
removeEventListener()and nullify any JavaScript variables that hold direct or indirect references to that element or its children. Integrate these cleanup steps into component unmount or destruction lifecycle methods. -
Are global variables always considered memory leaks in JavaScript?
Not always, but they are a common source. Explicitly declared global variables (e.g., for configuration or utility functions) are not inherently leaks if they are truly needed throughout the application's lifetime. However, unintended global variables (created without
var,let, orconstin non-strict mode) or global variables holding onto large, dynamically generated data that is no longer needed, certainly constitute memory leaks as they persist indefinitely, preventing garbage collection.