Mastering Memory Management in C#: Strategies to Detect and Prevent Memory Leaks

Memory leaks can be a persistent and damaging issue in software development, and .NET applications are susceptible to these challenges. Understanding and resolving memory leaks is crucial for maintaining the performance and reliability of your applications. In this article, we will explore the process of diagnosing memory leaks in .NET applications.

The Impact of Memory Leaks

Memory leaks can have severe consequences for your application’s performance, stability, and user experience. Here’s why memory leaks are considered bad and how they can affect an application:

1. Resource Consumption:

Memory leaks lead to a gradual consumption of system resources. Over time, as more memory is allocated but not properly released, the application’s footprint grows, potentially leading to increased disk swapping and degradation of overall system performance.

2. Application Sluggishness:

As memory usage continues to grow due to leaks, the application may become sluggish and less responsive. Users may experience delays in processing, slower UI interactions, and an overall degraded experience.

3. System Instability:

In extreme cases, uncontrolled memory leaks can result in system instability. The operating system may intervene by terminating the application or initiating other corrective measures to prevent widespread system degradation.

4. Increased Hardware Costs:

A memory-leaking application can lead to increased hardware costs. As the demand for memory grows, organizations may need to invest in additional hardware resources to support applications that are inefficient in managing memory.

5. User Frustration:

Users expect applications to run smoothly and without unexpected issues. Memory-related problems, such as crashes or slowdowns, can frustrate users and negatively impact the reputation of your software.

Understanding Memory Leaks

A memory leak is a situation in software development where a program allocates memory but fails to release it, leading to a gradual and unintended consumption of system resources. In the context of .NET applications, memory leaks often involve the mismanagement of memory by the Common Language Runtime (CLR).

Here’s a breakdown of how memory leaks occur and how to avoid it:

Event Handling Memory Leak

Code causing a memory leak:

    // Class with an event
    public class EventPublisher
    {
        public event EventHandler SomeEvent;

        public void InvokeEvent()
        {
            SomeEvent?.Invoke(this, EventArgs.Empty);
        }
    }

    // Class subscribing to the event
    public class EventSubscriber
    {
        private EventPublisher publisher;

        public EventSubscriber(EventPublisher pub)
        {
            publisher = pub;
            publisher.SomeEvent += HandleEvent;
        }

        private void HandleEvent(object sender, EventArgs e)
        {
            // Event handling logic
        }
    }

Why it causes a memory leak: The EventSubscriber subscribes to the SomeEvent of EventPublisher, but it doesn't unsubscribe. This means the EventSubscriber instance will keep the EventPublisher instance alive, preventing it from being garbage collected even when it's no longer needed.

Enhanced code to avoid the memory leak:

    public class EventPublisher
    {
        public event EventHandler SomeEvent;

        public void InvokeEvent()
        {
            SomeEvent?.Invoke(this, EventArgs.Empty);
        }
    }

    public class EventSubscriber
    {
        private EventPublisher publisher;

        public EventSubscriber(EventPublisher pub)
        {
            publisher = pub;
            publisher.SomeEvent += HandleEvent;
        }

        private void HandleEvent(object sender, EventArgs e)
        {
            // Event handling logic
        }

        public void Unsubscribe()
        {
            // Unsubscribe to prevent memory leak
            publisher.SomeEvent -= HandleEvent;
        }
    }

In the enhanced code, the EventSubscriber now has a Unsubscribe method. When you're done with the subscriber, call this method to unsubscribe from the event, preventing the memory leak.

Not Disposing IDisposable Objects

Code causing a memory leak:

    public class ResourceHolder : IDisposable
    {
        private MemoryStream memoryStream = new MemoryStream();

        public void DoSomething()
        {
            // Use the MemoryStream
        }

        // No Dispose method, causing a memory leak
    }

Why it causes a memory leak: The MemoryStream in the ResourceHolder class is not being disposed explicitly. This can lead to the MemoryStream not releasing resources promptly, causing a memory leak.

Enhanced code to avoid the memory leak:

    public class ResourceHolder : IDisposable
    {
        private MemoryStream memoryStream = new MemoryStream();

        public void DoSomething()
        {
            // Use the MemoryStream
        }

        public void Dispose()
        {
            // Dispose of the MemoryStream explicitly
            memoryStream.Dispose();
        }
    }

In the enhanced code, the Dispose method is implemented to explicitly dispose of the MemoryStream. This ensures proper cleanup of resources and avoids memory leaks.

Long-lived Objects in Caches

Code causing a memory leak:

public static class GlobalCache
{
    private static Dictionary<string, object> cache = new Dictionary<string, object>();

    public static void AddToCache(string key, object value)
    {
        cache[key] = value;
    }

    // No mechanism to remove items from the cache
}

Why it causes a memory leak: The GlobalCache stores objects indefinitely, leading to potential memory retention issues.

Enhanced code to avoid the memory leak:

public static class GlobalCacheFixed
{
    private static Dictionary<string, object> cache = new Dictionary<string, object>();

    public static void AddToCache(string key, object value)
    {
        cache[key] = value;
    }

    public static void RemoveFromCache(string key)
    {
        // Remove the item from the cache
        if (cache.ContainsKey(key))
        {
            cache.Remove(key);
        }
    }
}

In the enhanced code, a RemoveFromCache method is added to allow removing items from the cache, preventing long-lived memory retention.

Object Graphs “Complex Circular References”

Code causing a memory leak:

public class CircularReferenceExample
{
    public CircularReferenceExample()
    {
        Obj1 obj1 = new Obj1();
        Obj2 obj2 = new Obj2();

        obj1.Reference = obj2;
        obj2.Reference = obj1;
    }
}

public class Obj1
{
    public Obj2 Reference { get; set; }
}

public class Obj2
{
    public Obj1 Reference { get; set; }
}

Why it causes a memory leak: Circular references between Obj1 and Obj2 can lead to objects not being collected by the garbage collector.

Enhanced code to avoid the memory leak:

public class CircularReferenceExampleFixed
{
    public CircularReferenceExampleFixed()
    {
        Obj1 obj1 = new Obj1();
        Obj2 obj2 = new Obj2();

        obj1.Reference = new WeakReference<Obj2>(obj2);
        obj2.Reference = new WeakReference<Obj1>(obj1);
    }
}

public class Obj1
{
    public WeakReference<Obj2> Reference { get; set; }
}

public class Obj2
{
    public WeakReference<Obj1> Reference { get; set; }
}

In the enhanced code, WeakReference is used to break the circular references, allowing the garbage collector to collect objects properly.

Persistent object references

The GC cannot free objects that are referenced. Objects that are referenced but no longer needed result in a memory leak. If the app frequently allocates objects and fails to free them after they are no longer needed, memory usage will increase over time.

private static ConcurrentBag<string> _staticStrings = new ConcurrentBag<string>();

[HttpGet("staticstring")]
public ActionResult<string> GetStaticString()
{
    var bigString = new String('x', 10 * 1024);
    _staticStrings.Add(bigString);
    return bigString;
}

The preceding code is an example of a typical memory leak.
With frequent calls, causes app memory to increase until the process crashes with an OutOfMemory exception.

Large object heap

Frequent memory allocation/free cycles can fragment memory, especially when allocating large chunks of memory. Objects are allocated in contiguous blocks of memory. To mitigate fragmentation, when the GC frees memory, it tries to defragment it. This process is called compaction. Compaction involves moving objects. Moving large objects imposes a performance penalty. For this reason the GC creates a special memory zone for large objects, called the large object heap (LOH). Objects that are greater than 85,000 bytes (approximately 83 KB) are:

• Placed on the LOH.
• Not compacted.
• Collected during generation 2 GCs.

When the LOH is full, the GC will trigger a generation 2 collection. Generation 2 collections:

• Are inherently slow.
• Additionally incur the cost of triggering a collection on all other generations.

[HttpGet("loh/{size=85000}")]
public int GetLOH1(int size)
{
   return new byte[size].Length;
}

HttpClient

Incorrectly using HttpClient can result in a resource leak. System resources, such as database connections, sockets, file handles, etc.:

• Are more scarce than memory.
• Are more problematic when leaked than memory.

HttpClient implements IDisposable, but should not be disposed on every invocation. Rather, HttpClient should be reused.

The following endpoint creates and disposes a new HttpClient instance on every request:

[HttpGet("httpclient1")]
public async Task<int> GetHttpClient1(string url)
{
    using (var httpClient = new HttpClient())
    {
        var result = await httpClient.GetAsync(url);
        return (int)result.StatusCode;
    }
}

Even though the HttpClient instances are disposed, the actual network connection takes some time to be released by the operating system. By continuously creating new connections, ports exhaustion occurs. Each client connection requires its own client port.

One way to prevent port exhaustion is to reuse the same HttpClient instance:

private static readonly HttpClient _httpClient = new HttpClient();

[HttpGet("httpclient2")]
public async Task<int> GetHttpClient2(string url)
{
    var result = await _httpClient.GetAsync(url);
    return (int)result.StatusCode;
}

The HttpClient instance is released when the app stops. This example shows that not every disposable resource should be disposed after each use.

Unmanaged resources

Unmanaged resources in C# are resources that are not automatically managed by the .NET Common Language Runtime (CLR) garbage collector. They are typically external resources that need to be explicitly allocated and deallocated by the programmer. Examples of unmanaged resources include file handles, database connections, network sockets, and native memory allocations.

Code causing a memory leak:

using System;
using System.IO;

public class FileStreamLeakExample
{
    private FileStream fileStream;

    public FileStreamLeakExample(string filePath)
    {
        // Potential memory leak: FileStream is not properly cleaned up
        fileStream = new FileStream(filePath, FileMode.Open);
    }

    // No cleanup logic (no Dispose method or finalizer)

    // Note: Without proper cleanup, this class may lead to a memory leak
}

class Program
{
    static void Main()
    {
        FileStreamLeakExample leakyExample = new FileStreamLeakExample("example.txt");

        // The 'leakyExample' reference goes out of scope, but the file stream's resources may not be released.
    }
}

the FileStreamLeakExample class creates a FileStream but lacks proper cleanup, which may lead to a memory leak because the file stream's resources are not released when the instance goes out of scope.

Enhanced code to avoid the memory leak:

using System;
using System.IO;

public class FileStreamNoLeakExample
{
    public void ReadFile(string filePath)
    {
        // Using statement ensures proper cleanup of FileStream
        using (FileStream fileStream = new FileStream(filePath, FileMode.Open))
        {
            // Use the fileStream for reading, writing, etc.
            // For demonstration purposes, let's read and print the content
            using (StreamReader reader = new StreamReader(fileStream))
            {
                Console.WriteLine(reader.ReadToEnd());
            }
        } // The fileStream will be automatically disposed when exiting the outer using block
    }
}

class Program
{
    static void Main()
    {
        FileStreamNoLeakExample noLeakExample = new FileStreamNoLeakExample();

        // The 'noLeakExample' reference goes out of scope, and the FileStream is automatically disposed.
        noLeakExample.ReadFile("example.txt");
    }
}

In this example, the FileStreamNoLeakExample class uses the using statement to ensure proper cleanup of the FileStream. The StreamReader is also wrapped in another using statement for proper cleanup. This way, when the instance of FileStreamNoLeakExample goes out of scope, the FileStream and associated resources are automatically disposed of, preventing any potential memory leaks.