Memory Management in TypeScript: How the Garbage Collector Works

Memory and Garbage Collector in TypeScript: What's Behind the Scenes?

Imagine you are building a house. You buy bricks, cement, rebar — but if you don't clean up the construction debris, the site will soon turn into a dump. The same thing happens in your TypeScript code. You create objects, arrays, closures — and if you don't free up memory in time, the application starts to slow down, and then crashes with an Out of Memory error.

In this article, we will break down how memory management in TypeScript works and its main tool — the garbage collector. You will learn what mechanisms are behind memory deallocation, how to avoid leaks, and why your code can "eat" megabytes even after you stop using it.

Let's go!

How Does TypeScript Manage Memory? The Basics

Let's start with an important point: TypeScript is not a separate language, but a superset of JavaScript. This means that memory and the garbage collector in TypeScript work exactly the same as in JavaScript. TypeScript does not add new memory management mechanisms, but it gives us tools (types, interfaces) to write safer code.

In JavaScript, memory is divided into two main areas:

\n
• Stack — stores primitives (numbers, strings, booleans) and references to objects. It is automatically freed when a function exits.
\n
• Heap — stores objects, arrays, functions. This is where the garbage collector works.
\n

When you write:

const user = { name: 'Alice', age: 30 };

The variable user is stored on the stack and contains a reference to the object in the heap. As long as there is a reference, the object is alive. Once the reference disappears, the object becomes "garbage".

Garbage Collector in TypeScript: How Does It Work?

The garbage collector (GC) is an automatic process that finds objects that are no longer referenced and frees the memory they occupy. Modern engines (V8 in Chrome, SpiderMonkey in Firefox) use complex algorithms, but the foundation is the Mark-and-Sweep algorithm.

How it works:

\n
1. The GC starts from "roots" — global objects, local variables in executing functions.
\n
2. It traverses all references from the roots and marks every reachable object.
\n
3. All unmarked objects are considered garbage and are removed.
\n

Sounds simple, but in practice there are nuances. For example, circular references:

function createCycle() {\n    const obj1: any = {};\n    const obj2: any = {};\n    obj1.ref = obj2;\n    obj2.ref = obj1;\n    return 'done';\n}

In the past, such structures led to leaks, but modern garbage collectors handle cycles perfectly — the main thing is that both objects are unreachable from the roots.

Typical Memory Leaks in TypeScript Applications

Even with a smart garbage collector, you can "step on a rake". Here are the most common scenarios that lead to memory leaks in TypeScript:

1. Forgotten Timers and Event Handlers

One of the most common causes. You subscribed to an event but forgot to unsubscribe:

class TimerComponent {\n    private intervalId: number;\n\n    start() {\n        this.intervalId = window.setInterval(() => {\n            console.log('Tick');\n        }, 1000);\n    }\n\n    // Forgot to call stop() — the timer will live forever!\n}

Solution: always clear timers and unsubscribe from events in the dispose or ngOnDestroy method (for Angular).

2. Closures That Hold References

Closures are a powerful tool, but they can accidentally hold onto huge objects:

function createHeavyClosure() {\n    const hugeData = new Array(1000