Finding Memory Leaks in Long-Running .NET Worker Services

public class OrderProcessor
{
    private const int MaximumItems = 100;

    private readonly Queue<Order> _recentOrders = new();

    public void Process(Order order)
    {
        _recentOrders.Enqueue(order);

        while (_recentOrders.Count > MaximumItems)
        {
            _recentOrders.Dequeue();
        }
    }
}

This limits the collection to the latest 100 orders.

However, the best solution may be to remove the collection entirely if the application does not need it.

For operational history, use a database or logging system rather than keeping an unlimited collection in application memory.

Avoid Event Handler Memory Leaks

Event subscriptions can also prevent objects from being collected.

Consider a service that subscribes to an event:

public class OrderNotificationService
{
    public OrderNotificationService(
        OrderEventPublisher publisher)
    {
        publisher.OrderCreated += OnOrderCreated;
    }

    private void OnOrderCreated(
        object? sender,
        EventArgs e)
    {
        // Handle notification
    }
}

If the publisher is a singleton and the notification service is created repeatedly, the publisher may retain references to old service instances through its event handlers.

The objects cannot be collected while those references remain.

Unsubscribe when the service is no longer needed:

public class OrderNotificationService : IDisposable
{
    private readonly OrderEventPublisher _publisher;

    public OrderNotificationService(
        OrderEventPublisher publisher)
    {
        _publisher = publisher;

        _publisher.OrderCreated += OnOrderCreated;
    }

    private void OnOrderCreated(
        object? sender,
        EventArgs e)
    {
        // Handle notification
    }

    public void Dispose()
    {
        _publisher.OrderCreated -= OnOrderCreated;
    }
}

In dependency-injection applications, also make sure that service lifetimes are correct.

A singleton should not retain references to scoped services beyond their intended lifetime.

Dispose Resources Properly

Managed memory is only one part of memory management.

Streams, database connections, file handles, and other resources may use unmanaged memory or operating system resources.

Use using or await using to ensure that disposable resources are released.

For example:

public async Task ProcessFileAsync(
    string filePath,
    CancellationToken cancellationToken)
{
    await using var stream = new FileStream(
        filePath,
        FileMode.Open,
        FileAccess.Read,
        FileShare.Read,
        bufferSize: 81920,
        useAsync: true);

    using var reader = new StreamReader(stream);

    var content = await reader.ReadToEndAsync(
        cancellationToken);

    // Process the file content
}

For large files, avoid reading the entire file into memory when it is not necessary. Process the data in smaller chunks or line by line.

Also, follow the disposal rules of the libraries you use. For example, do not dispose an HTTP client obtained from IHttpClientFactory after every request. The factory manages the underlying handler lifecycle.

Avoid Creating Large Objects Unnecessarily

The Large Object Heap stores large managed objects, including arrays and strings that meet the runtime's large-object allocation threshold.

Repeatedly allocating large arrays can increase memory pressure.

Consider this example:

public byte[] ProcessLargeData()
{
    var buffer = new byte[10 * 1024 * 1024];

    // Process data

    return buffer;
}

A worker that executes this method repeatedly can create significant allocation pressure.

When appropriate, use ArrayPool<T> to reuse buffers:

using System.Buffers;

public void ProcessData()
{
    var buffer = ArrayPool<byte>.Shared.Rent(
        1024 * 1024);

    try
    {
        // Use the buffer for processing
    }
    finally
    {
        ArrayPool<byte>.Shared.Return(
            buffer,
            clearArray: true);
    }
}

Returning the buffer allows another operation to reuse it.

Use clearArray: true when the buffer may contain sensitive data and clearing it is required by your security policy.

Do not return a buffer while another operation is still using it.

Review Background Task Lifetimes

Long-running workers often create additional asynchronous tasks.

An unsafe pattern is starting a task without tracking its lifetime:

public void StartProcessing()
{
    Task.Run(async () =>
    {
        await ProcessOrdersAsync();
    });
}

The application has no clear way to observe failures, coordinate cancellation, or wait for the task during shutdown.

Use the hosted service lifecycle instead.

public class OrderWorker : BackgroundService
{
    private readonly ILogger<OrderWorker> _logger;

    public OrderWorker(
        ILogger<OrderWorker> logger)
    {
        _logger = logger;
    }

    protected override async Task ExecuteAsync(
        CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
                await ProcessOrdersAsync(stoppingToken);
            }
            catch (OperationCanceledException)
                when (stoppingToken.IsCancellationRequested)
            {
                break;
            }
            catch (Exception ex)
            {
                _logger.LogError(
                    ex,
                    "Order processing failed.");
            }

            await Task.Delay(
                TimeSpan.FromSeconds(5),
                stoppingToken);
        }
    }

    private async Task ProcessOrdersAsync(
        CancellationToken cancellationToken)
    {
        // Process pending orders
        await Task.CompletedTask;
    }
}

This provides a clear lifecycle for the background operation.

If a worker needs scoped services such as an EF Core DbContext, create a dependency-injection scope for each processing unit. Do not retain a scoped context in a singleton worker indefinitely.

Best Practices for Long-Running Workers

Monitor memory trends

Collect memory metrics continuously. Compare heap size, allocation rate, and working set against processing volume.

Keep collections bounded

Use limits for caches, queues, dictionaries, and in-memory history.

Review service lifetimes

Check whether singleton services retain references to scoped or transient objects.

Dispose resources

Use the correct disposal pattern for streams, database resources, and other disposable objects.

Process large data incrementally

Avoid loading entire files or large database result sets into memory when streaming or pagination is possible.

Test under sustained load

A worker that runs successfully for five minutes may still have a memory leak after several hours.

Avoid forcing garbage collection

Calling GC.Collect() repeatedly is not a reliable way to fix memory leaks. It can increase CPU usage and hide the actual object retention problem.

Common Mistakes to Avoid

One common mistake is treating high working set memory as proof of a memory leak. The .NET runtime may retain memory for reuse even after objects are collected.

Another mistake is looking only at allocation rate. High allocations do not necessarily indicate a leak if objects have short lifetimes.

Developers also sometimes increase container memory limits instead of investigating continuously growing object graphs. This may delay the failure without fixing the underlying problem.

Finally, avoid capturing memory dumps without considering security. Dumps may contain sensitive application data and should be handled like production data.

Summary

Memory leaks in long-running .NET worker services usually occur because objects remain reachable longer than necessary or resources are not released correctly.

Start by monitoring runtime counters and memory trends. Capture memory dumps when needed, inspect object types, and use reference analysis to find what keeps objects alive.

Fix unbounded collections, event subscriptions, incorrect service lifetimes, and unnecessary large allocations. Combine these changes with sustained-load testing and production monitoring.

A worker service should maintain predictable memory usage as its workload grows. The goal is not to force the garbage collector to run more often, but to ensure that the application releases objects and resources when they are no longer needed.