A memory leak occurs when a computer program allocates memory but fails to release it even though it's no longer needed. In the context of an Angular application, memory leaks can happen due to a variety of reasons:

1️⃣ The most common cause of memory leaks in Angular applications are subscriptions on Observables, which do not get unsubscribed 🤯

When you create a subscription on an observable in a component class and don't unsubscribe when the component is destroyed, the subscription lives on, and memory stays allocated for the subscription. The next time you open the same component, you create another subscription, so at this point, you have 2 subscriptions on the same observable. This process keeps on repeating until you don't have any memory left, and the application crashes 💣

A good way to avoid this and improve your app performance in the process is by handling your subscriptions in components using the ASYNC pipe. The ASYNC pipe unsubscribed automatically for you, combined with the OnPush change detection app performance will also improve quite a bit 🔥

2️⃣ Not cleaning up events 😭

Another reason why memory leaks can pop up is event listeners, which are registered and not cleaned up. If you register events the Angular way using the @HostListener decorator, Angular will actually mostly clean them up for you to prevent memory leaks! 👩‍🚒

3️⃣ Not clearing timers

To start you shouldn't use settimeout or setInterval and use a more reactive approach. But when do use setTimeout or setInterval you should clear them when the component is destroyed! Not cleaning up settimeout and setinterval can lead to memory leaks and are some of the most common cases!

🔍Detecting memory leaks in Angular applications🔍

• On Chrome, right-click on the screen and open the inspector.
• Go to more options -> more tools.
• Select performance monitor.
• The performance monitor features a visual representation that showcases fluctuations in memory, CPU usage, JS heap size, and more. Pay close attention to these visual cues and numerical data, then navigate to the suspected component harboring the issue. Consider altering components or, when dealing with a list of items, interact with various ones to discern any significant disparities reflected in the graph. If the memory or heap size jumps substantially and fails to decrease upon returning to the initial point, even after triggering the garbage collector, it indicates a memory leak.

Chrome has a garbage collector that runs after every few minutes. You can run it manually from the memory tab in the browser dev tools.

• You can also figure out which objects are being retained through heap snapshots. In the memory tab, take a heap snapshot before clicking on the component that is causing trouble. Then take another heap snapshot and compare!
• Lastly, you use console logs and see if they start to duplicate over time when you leave and enter the component.

I hope you found it useful. Thanks for reading. 🙏
Let's get connected! You can find me on:

• Medium: https://medium.com/@nhannguyendevjs/
• Dev: https://dev.to/nhannguyendevjs/
• Substack: https://nhannguyendevjs.substack.com/
• Linkedin: https://www.linkedin.com/in/nhannguyendevjs/
• X (formerly Twitter): https://twitter.com/nhannguyendevjs/