.NET Documentation

Garbage Collection in .NET

Garbage collection (GC) is an automatic memory management feature in the .NET runtime. It reclaims memory occupied by objects that are no longer in use by the application. This frees developers from manually allocating and deallocating memory, significantly reducing the risk of memory leaks and other common memory-related bugs.

How Garbage Collection Works

The .NET GC operates on a generational, mark-and-sweep algorithm. Here's a simplified overview:

• Object Allocation: When an object is created, it's allocated in the managed heap.
• Root Set: The GC identifies a set of "roots." These are references to objects that the application can directly access. This includes static variables, local variables on the stack, and CPU registers.
• Marking: The GC traverses the object graph starting from the root set. It marks all objects that are reachable from the roots as "live." Any object not marked is considered unreachable.
• Sweeping/Compacting:
  • Sweeping: The GC iterates through the heap. Any object that was not marked is considered garbage and its memory is reclaimed.
  • Compacting: To combat heap fragmentation, the GC can move live objects closer together in memory. This creates larger contiguous blocks of free memory, which can improve allocation performance.

Generational Garbage Collection

The .NET GC employs a generational approach to optimize performance. The managed heap is divided into generations:

• Generation 0: This generation holds the youngest objects, i.e., those most recently allocated. Most objects have a short lifespan and are eligible for collection here.
• Generation 1: Objects that survive a GC in Generation 0 are promoted to Generation 1.
• Generation 2: Objects that survive a GC in Generation 1 are promoted to Generation 2. This generation typically holds the longest-lived objects.

The GC performs collections more frequently on younger generations (Generation 0) because it's statistically more likely for objects in these generations to be garbage. This reduces the overhead of scanning the entire heap for every collection.

Configuring Garbage Collection

While the GC is largely automatic, you can influence its behavior using configuration settings and specific API calls.

GC Modes:

• Workstation GC: Optimized for client applications, where responsiveness is paramount. It aims to minimize pauses by performing collections on a single thread.
• Server GC: Optimized for server applications, where throughput is the primary concern. It uses multiple threads for garbage collection, allowing for higher performance on multi-processor systems.

Server GC is the default for ASP.NET applications and services, while Workstation GC is the default for desktop applications.

Manual Triggering:

In certain scenarios, you might want to explicitly trigger a garbage collection. Use the GC.Collect() method with caution, as it can introduce performance overhead if used inappropriately.

// Request a full, blocking garbage collection
GC.Collect();

// Request a generation-specific collection
GC.Collect(0);
GC.Collect(1);
GC.Collect(2);
                    

Finalization and Dispose Pattern

For objects that manage unmanaged resources (like file handles, network connections, or database connections), you need to ensure these resources are released when the object is no longer needed. This is typically handled using the Dispose pattern.

• Finalizers (Destructors): A finalizer (using `~ClassName()` syntax) is a last-resort mechanism to release unmanaged resources if the object's `Dispose()` method is not called. However, finalizers are unpredictable in their execution timing and can impact performance.
• IDisposable Interface: The recommended approach is to implement the IDisposable interface and its Dispose() method. This provides a deterministic way to release resources. The using statement in C# is a convenient way to ensure that Dispose() is called.

public class MyResourceHolder : IDisposable
{
    private IntPtr unmanagedHandle;

    public MyResourceHolder()
    {
        // Allocate unmanaged resources
        unmanagedHandle = AllocateUnmanagedMemory();
    }

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

    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            // Release managed resources here if any
        }

        // Release unmanaged resources
        if (unmanagedHandle != IntPtr.Zero)
        {
            ReleaseUnmanagedMemory(unmanagedHandle);
            unmanagedHandle = IntPtr.Zero;
        }
    }

    ~MyResourceHolder()
    {
        // Finalizer: Only release unmanaged resources
        Dispose(false);
    }

    // ... other methods ...
}

// Using the resource
using (var holder = new MyResourceHolder())
{
    // Use the object
} // Dispose() is automatically called here
                    

Best Practices

• Avoid creating objects with very short lifespans in tight loops if performance is critical.
• Understand the difference between Workstation and Server GC and configure appropriately for your application type.
• Implement the IDisposable pattern for classes that manage unmanaged resources.
• Use the using statement for deterministic resource management.
• Avoid excessive use of finalizers.
• Be mindful of large object allocations, which can lead to increased GC pressure.