Reactive Programming: The Spit Take on Memory Leaks
Description
A meme illustrating a common beginner's mistake in reactive programming. The image shows a woman and a young child at a birthday party. The woman, leaning in with a smile, has text over her that reads, 'Me a beginner in reactive programming'. The child is leaning forward to blow out a single candle on a chocolate cake, but instead of just air, a fine spray of saliva is erupting from their mouth onto the cake. This spray is labeled 'An unsubscribed event'. The humor lies in the visceral and messy visual representation of a technical problem. In reactive paradigms (like RxJS), failing to unsubscribe from an event stream when a component is destroyed can lead to memory leaks and unexpected behaviors, as the subscription continues to exist and fire in the background - much like the child's unending, messy spray long after the 'blowing' action should have been completed
Comments
7Comment deleted
Forgetting to unsubscribe from an observable is the asynchronous version of leaving a database connection open. Eventually, the pool runs out, and your app just sits there, drooling on itself
Nothing like realizing your “disposed” subscription is still next()-spamming the UI - apparently I’d invented Schrödinger’s Observer: simultaneously dead and saturating prod logs
After 15 years of fixing production memory leaks, I've learned that unsubscribed observables are like that one contractor who keeps billing after the project ends - except instead of money, they're stealing heap space and your weekend plans when the OOM killer shows up at 3 AM
Every senior engineer remembers their first production memory leak from forgetting to unsubscribe - watching heap dumps grow like a birthday cake that never stops expanding. The real rite of passage isn't learning reactive programming; it's debugging why your SPA now consumes 4GB of RAM after users navigate between routes a few times, only to discover you've been accumulating event listeners like Pokémon cards since the component mounted
Unsubscribed hot observable: the reactive dev's reminder that backpressure isn't optional at scale
Unsubscribe() detaches you, not the hot source - without takeUntil(destroy$), your Subject keeps multicasting like this kid, and your component tree gets a very moist memory leak
Reactive lesson: “unsubscribe” doesn’t stop a hot observable - if refCount > 0 the upstream keeps blowing side effects; the only thing disposed was my illusion of control