August 21, 2025

Understanding Garbage Collection and Resource Management in C#

When you write C# code, you rarely have to think about memory management. The .NET runtime takes care of allocating and freeing memory for you, thanks to a system called the garbage collector (GC). But to write efficient, reliable applications—especially those that interact with files, databases, or other system resources—it’s important to understand how the GC works, what its limitations are, and how you can help it do its job.

What is Garbage Collection?

Garbage collection is the process by which .NET automatically finds and frees memory that your program no longer needs. When you create an object with new, it’s stored on the heap—a region of memory managed by the runtime. As long as your code holds a reference to that object, it stays alive. But once there are no more references, the object becomes “garbage,” and the GC will eventually reclaim its memory. This process is automatic and happens in the background. You don’t need to explicitly free most objects, which helps prevent memory leaks and many common bugs found in languages like C or C++.

How Does the Garbage Collector Work?

The .NET garbage collector uses a strategy called “mark, sweep, and compact".

  • Mark: The GC starts by pausing your program briefly and looking for all objects that are still in use (reachable from variables, static fields, etc.). These are “marked” as alive.
  • Sweep: Any objects not marked are considered garbage. Their memory is released.
  • Compact: To avoid fragmentation (holes in memory), the GC moves the remaining objects together, so new objects can be allocated efficiently.

Visual Example: Compaction

  • Before Compaction: Objects are scattered across memory, leaving gaps of unused space in between.
  • After Compaction: Surviving objects are packed together, and free space is consolidated on one side, making allocation faster and more efficient.

Why Generations Matter

When the garbage collector reclaims memory, it doesn’t treat all objects the same way. Instead, it uses the idea of generations to make collection more efficient.

The reasoning is based on a simple observation:

  • Most objects in a program are short-lived (like temporary strings, method-local data, or intermediate results).
  • A smaller number of objects are long-lived (like configuration objects, caches, or services that stay active throughout the application).

To optimize for this behavior, the GC groups objects into generations:

  • Generation 0: This is where all new objects are created. Because most objects die quickly, Gen 0 is collected very frequently.
  • Generation 1: If an object survives a Gen 0 collection, it is promoted to Gen 1. This acts as a “middle ground” between short-lived and long-lived objects.
  • Generation 2: Objects that survive even longer are promoted here. Gen 2 contains long-lived objects and is collected far less often, since scanning it is more expensive.

This generational model allows the GC to focus its work where it’s most effective—reclaiming memory from short-lived objects—without repeatedly scanning objects that are known to be long-lived.

The Large Object Heap (LOH)

There is one special case: very large objects. If you allocate an object larger than about 85,000 bytes (for example, a big array or buffer), it is placed in the Large Object Heap (LOH).

The LOH behaves differently:

  • It is only collected during the most expensive GC cycles.
  • By default, it is not compacted, which means large allocations and deallocations can lead to memory fragmentation.

If your application frequently creates and discards large objects, you may encounter performance issues or even run out of memory, even if you’re not leaking references.

The Limits of Garbage Collection: Unmanaged Resources

Here’s the crucial limitation: the garbage collector only knows about memory managed by .NET. It does not know how to free resources that live outside the .NET world—called unmanaged resources.

Examples include:

  • File handles
  • Database connections
  • Network sockets

If you don’t release these resources manually, they can be exhausted. For example:

  • Opening many files without closing them can hit the OS limit for open files.
  • Leaving database connections open can exhaust the connection pool.

The GC will eventually clean up objects that wrap unmanaged resources, but it does so on its own unpredictable schedule. That means a file or database connection could stay open much longer than expected, causing instability.

Dispose Pattern and Finalizers

To bridge this gap, .NET provides two key mechanisms: the Dispose Pattern and Finalizers. They work together to ensure that both managed and unmanaged resources are released correctly.

The Dispose Pattern

The Dispose Pattern is a standardized way for classes to clean up their resources deterministically. It’s based on the IDisposable interface:

public interface IDisposable
{
    void Dispose();
}

When you implement Dispose(), you allow users of your class to explicitly release resources as soon as they’re no longer needed, rather than waiting for the GC.

Example: Dispose Pattern in Action

public class FileManager : IDisposable
{
    private FileStream file;          // Managed resource
    private IntPtr unmanagedBuffer;   // Unmanaged resource
    private bool disposed = false;

    public FileManager(string path)
    {
        file = new FileStream(path, FileMode.Create);
        unmanagedBuffer = Marshal.AllocHGlobal(100); // allocate native memory
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this); // Prevent finalizer from running
    }

    protected virtual void Dispose(bool disposing)
    {
        if (disposed) return;

        if (disposing)
        {
            // Free managed resources
            file?.Dispose();
        }

        // Free unmanaged resources
        if (unmanagedBuffer != IntPtr.Zero)
        {
            Marshal.FreeHGlobal(unmanagedBuffer);
            unmanagedBuffer = IntPtr.Zero;
        }

        disposed = true;
    }

    ~FileManager()
    {
        Dispose(false); // Finalizer path
    }
}

Key Details:

  • Dispose(true) → Called by user code (Dispose() or using). It is safe to free both managed and unmanaged resources.

  • Dispose(false) → Called by the finalizer. Only unmanaged resources should be freed, since managed ones may already be collected.

  • GC.SuppressFinalize(this) → Prevents the finalizer from running unnecessarily if Dispose() was already called.

Finalizers

A finalizer is a backup mechanism. It’s a method that the GC calls right before reclaiming an object’s memory:

~FileManager()
{
    Dispose(false);
}

  • Finalizers are non-deterministic — you cannot know when they will run.

  • Objects with finalizers also live longer because they must survive until the GC’s finalization queue runs.

  • This makes finalizers more expensive and less predictable than Dispose().

When Is the Finalizer Called?

This is a common source of confusion. The finalizer is only called if Dispose() (or using) was not used.

  • If you wrap your object in a using block or call Dispose() explicitly, the finalizer is suppressed with GC.SuppressFinalize(this).
  • If you forget to dispose of the object, then when the GC eventually collects it, the finalizer runs as a safety net to release unmanaged resources.

However:

  • You don’t control when the GC runs.
  • That means unmanaged resources (like file handles or sockets) could remain open far longer than you intended.

Best Practice: Always use using or explicitly call Dispose(). The finalizer should only be there as a last resort.

Conclusion

The .NET Garbage Collector makes memory management automatic, but it does not clean up unmanaged resources like files, sockets, or database connections.

That’s why the Dispose pattern is essential: it lets you release resources right away, using Dispose() or a using block. Finalizers exist only as a backup if Dispose() is not called, but they are slower and less predictable.

In practice:

  • Always implement IDisposable when working with unmanaged resources.
  • Always call Dispose() (or use using).
  • Rely on finalizers only as a safety net.

By following these rules, your applications will avoid leaks, use resources efficiently, and run more reliably.

References