What is memory leak in Angular and how to prevent it?

A memory leak in Angular applications occurs when memory allocated for objects is not released even after those objects are no longer needed, leading to increased memory consumption and degraded application performance. This typically happens when references to components, subscriptions, or event listeners persist beyond their lifecycle.

What is a Memory Leak?

A memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations, causing memory that is no longer needed to not be released. In the context of web applications, this often means that DOM elements, JavaScript objects, or closures are retained in memory unnecessarily, preventing the garbage collector from reclaiming that memory.

Common Causes of Memory Leaks in Angular

• Unsubscribed Observables/Subscriptions: Observables (especially long-lived ones like interval, fromEvent, or custom subjects) that are not unsubscribed from when the component is destroyed.
• Dangling Event Listeners: Manually added event listeners (e.g., using addEventListener) that are not removed when the component is no longer in use.
• Improperly Destroyed Components: Dynamically created components or services that hold references to components that are no longer part of the DOM tree.
• Global Variables and Caches: Objects stored in global scopes or caches without proper cleanup, retaining references to other objects.
• Circular References: Though less common with modern JavaScript garbage collectors, complex circular references can sometimes prevent objects from being collected.

How to Prevent Memory Leaks in Angular

1. Unsubscribing from Observables

This is the most frequent cause of memory leaks. You must unsubscribe from any long-lived observables when the component that subscribed to them is destroyed. HTTP requests typically complete and clean up on their own, but others like interval, fromEvent, or custom subjects require explicit handling.

Using Subscription.unsubscribe() in ngOnDestroy:

import { Component, OnDestroy } from '@angular/core';
import { Subscription, interval } from 'rxjs';

@Component({
  selector: 'app-my-component',
  template: `<h1>{{ count }}</h1>`
})
export class MyComponent implements OnDestroy {
  private mySubscription: Subscription;
  count: number = 0;

  constructor() {
    this.mySubscription = interval(1000).subscribe(val => {
      this.count = val;
    });
  }

  ngOnDestroy(): void {
    this.mySubscription.unsubscribe();
  }
}

Using RxJS takeUntil operator (recommended for multiple subscriptions):

import { Component, OnDestroy } from '@angular/core';
import { Subject, interval } from 'rxjs';
import { takeUntil } from 'rxjs/operators';

@Component({
  selector: 'app-another-component',
  template: `<h1>{{ value }}</h1>`
})
export class AnotherComponent implements OnDestroy {
  private destroy$ = new Subject<void>();
  value: number = 0;

  constructor() {
    interval(1000)
      .pipe(takeUntil(this.destroy$))
      .subscribe(val => {
        this.value = val;
      });

    // Another observable using the same destroy$ subject
    // ...
  }

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

Using async pipe in templates (Angular handles cleanup automatically):

<div *ngIf="data$ | async as data">
  {{ data }}
</div>

2. Removing Event Listeners

If you manually attach event listeners (e.g., to the window or document), ensure they are removed when the component is destroyed. Angular's built-in event binding syntax (event)="handler()" handles cleanup automatically.

import { Component, OnInit, OnDestroy, ElementRef } from '@angular/core';

@Component({
  selector: 'app-event-listener',
  template: `<button>Click Me</button>`
})
export class EventListenerComponent implements OnInit, OnDestroy {
  constructor(private el: ElementRef) {}

  ngOnInit(): void {
    // Attaching an event listener manually
    this.el.nativeElement.addEventListener('click', this.handleClick);
  }

  handleClick = () => {
    console.log('Button clicked!');
  };

  ngOnDestroy(): void {
    // Removing the event listener
    this.el.nativeElement.removeEventListener('click', this.handleClick);
  }
}

3. Properly Destroying Dynamic Components and Services

When dynamically creating components using ComponentFactoryResolver, remember to call componentRef.destroy() when they are no longer needed. Similarly, ensure that services don't hold long-lived references to components or DOM elements that prevent garbage collection.

4. Avoiding Global Variables and Uncontrolled Caches

Minimize the use of global variables. If used, ensure their references are explicitly set to null or undefined when the objects they point to are no longer needed. Be mindful of custom caches that might grow indefinitely without proper eviction policies.

Tools for Detecting Memory Leaks

• Chrome DevTools Memory Tab: Use 'Heap snapshots' to compare memory states before and after performing actions that might cause a leak (e.g., navigating to and from a component). 'Allocation instrumentation on timeline' can show real-time memory allocation patterns.
• Firefox Developer Tools Memory Tool: Offers similar capabilities for analyzing memory usage.
• Angular DevTools: Can help in understanding component lifecycle, change detection, and identifying detached components that might still be in memory.

Proactive management of subscriptions, event listeners, and dynamic resources is crucial for building performant and stable Angular applications. Regularly profiling your application with browser developer tools can help identify and resolve potential memory leaks early in the development cycle, leading to a much better user experience.