Unsubscribing and memory leaks in Angular - Step-by-Step Execution

Concept Flow - Unsubscribing and memory leaks

Component Initialized

↓

Subscribe to Observable

↓

Component Uses Data

↓

Component Destroyed

↓

Unsubscribe from Observable

↓

Memory Freed

↓

No Memory Leak

↓

Component Destroyed

↓

Subscription Remains Active

↓

Memory Leak Occurs

Shows how subscribing to data streams must be paired with unsubscribing when a component is destroyed to avoid memory leaks.

Execution Sample

Angular

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

@Component({ selector: 'app-demo', template: '' })
export class DemoComponent implements OnDestroy {
  sub: Subscription;
  constructor() {
    this.sub = someObservable.subscribe();
  }
  ngOnDestroy() {
    this.sub.unsubscribe();
  }
}

This Angular component subscribes to an observable and unsubscribes when destroyed to prevent memory leaks.

Execution Table

Step	Action	Subscription State	Memory Status
1	Component created	No subscription	No memory used by subscription
2	Subscribe to observable	Subscription active	Memory allocated for subscription
3	Component uses data	Subscription active	Memory in use
4	Component destroyed	Subscription active	Memory still allocated (potential leak)
5	Unsubscribe called	Subscription closed	Memory freed
6	Component fully cleaned	No subscription	No memory leak

💡 Unsubscribe must be called on destroy to free memory and avoid leaks

Variable Tracker

Variable	Start	After Step 2	After Step 5	Final
sub	undefined	Subscription object (active)	Subscription object (closed)	undefined or garbage collected

Key Moments - 3 Insights

Why do we need to unsubscribe in ngOnDestroy?

Because the subscription stays active after the component is destroyed (see step 4 in execution_table), causing memory to stay allocated and leading to leaks.

What happens if we forget to unsubscribe?

The subscription remains active (step 4), so memory is not freed, which can slow down or crash the app over time.

Is unsubscribing necessary for all observables?

Not always. Some observables complete automatically, but for long-lived or infinite streams, unsubscribing is essential to prevent leaks.

Visual Quiz - 3 Questions

Look at the execution_table, what is the subscription state at step 4?

A Subscription closed

B Subscription active

C No subscription

D Subscription error

💡 Hint

Check the 'Subscription State' column at step 4 in the execution_table

At which step is memory freed according to the execution_table?

A Step 5

B Step 2

C Step 4

D Step 6

💡 Hint

Look at the 'Memory Status' column to find when memory is freed

If we remove the unsubscribe call, what will happen to the memory status after component destruction?

A Memory freed immediately

B Subscription closes automatically

C Memory remains allocated causing a leak

D Component will not destroy

💡 Hint

Refer to the exit_note and step 4 in execution_table about missing unsubscribe

Concept Snapshot

Angular components subscribing to observables must unsubscribe in ngOnDestroy.
Failing to unsubscribe keeps subscriptions active.
Active subscriptions hold memory causing leaks.
Unsubscribe frees memory and prevents leaks.
Use Subscription object and call unsubscribe() on destroy.

Full Transcript

In Angular, when a component subscribes to an observable, it creates a subscription that holds resources in memory. If the component is destroyed but the subscription is not unsubscribed, the subscription stays active, causing memory to remain allocated. This leads to memory leaks which can degrade app performance. To prevent this, Angular components implement the ngOnDestroy lifecycle hook where they call unsubscribe() on their subscriptions. This closes the subscription and frees memory. The execution table shows the subscription state and memory status step-by-step, highlighting the importance of unsubscribing. Beginners often confuse when to unsubscribe and why it matters. Remember, unsubscribing is essential for long-lived observables to keep your app healthy and fast.