Managing Application Memory Pressure

In this lesson, you will learn how to identify and mitigate memory leaks within long-running BackgroundService implementations to prevent your application from crashing under sustained load.

The Hidden Trap of Background Workers

When running background tasks, developers often fall into the trap of using static collections or event subscriptions that live for the entire duration of the application. In a BackgroundService, which usually runs until the host shuts down, any object added to a static list or a long-lived event handler that is not removed will never be garbage collected. This causes a slow, steady climb in memory usage—a classic memory leak.

Identifying the Leak

The most common culprit is the captured closure. If your background loop subscribes to a service event to process messages, and that service outlives the loop, the closure captures the scope and prevents it from being cleared.

Consider this problematic pattern:

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    // If _messageSource is a singleton, this event subscription 
    // will keep this service instance alive and leak memory 
    // if the service was intended to be transient/scoped.
    _messageSource.MessageReceived += OnMessageReceived;

    await Task.Delay(Timeout.Infinite, stoppingToken);
}

Mitigation Strategies

To keep memory pressure under control:

1. Weak Event Pattern: If you must subscribe to events on long-lived objects, use the Weak Event pattern to ensure the subscriber can still be garbage collected.
2. Clear Collections: If you maintain an internal buffer or queue for processing, ensure you use ConcurrentQueue or Channel<T> with strict capacity limits. A collection that grows unbounded is a ticking time bomb.
3. Dispose Carefully: Always override the Dispose or DisposeAsync method of your BackgroundService. Even if the service is a singleton, explicitly nullifying large objects or clearing event subscriptions when the host begins its graceful shutdown ensures the memory is reclaimed immediately rather than waiting for the process to exit.
4. Use Channel<T>: Prefer System.Threading.Channels over manual List<T> buffers. Channels provide built-in backpressure mechanisms, allowing you to limit how many items are held in memory before the producer is forced to slow down.

Key Takeaway: To prevent memory leaks in background workers, strictly manage event unsubscriptions and enforce capacity limits on internal buffers to ensure objects remain eligible for garbage collection.