.NET Garbage Collection Explained: How the GC Works

You've never called free() in C#. Something else has been doing that job, silently, this entire time.

Every new Customer(), every new List<int>(), every object you've ever created across two entire books of lessons has gone somewhere — and, eventually, has been cleaned up. You never wrote code to release that memory. You never even had to think about it. That's not because memory management is unnecessary in .NET; it's because someone else is doing it for you, continuously, in the background, for the entire life of your program.

That someone is the Garbage Collector (GC) — arguably the single most consequential CLR service you've been relying on, and the one this whole tier has been building toward. It's time to actually understand what it does and how.

In this lesson, you'll learn why automatic memory management exists, what "garbage" actually means to the runtime, and how the GC decides what's safe to reclaim and when.

What Is It?

The Simple Explanation

The Garbage Collector is a part of the CLR that periodically looks at everything currently on the managed heap, figures out which objects your program can no longer possibly reach, and frees the memory those unreachable objects were using — automatically, without you writing any cleanup code.

The Technical Definition

The GC is a tracing, reachability-based automatic memory manager. It does not track "how many things point at this object" (that's a different technique called reference counting, used by some other languages). Instead, periodically, it starts from a known set of roots — local variables currently on the stack, static fields, CPU registers holding object references — and walks the graph of everything reachable from those roots. Anything not reachable this way is, by definition, garbage: your program has no possible way to ever use it again, so it's safe to reclaim.

Why Does It Exist?

The Problem — manual memory management is genuinely dangerous

In languages without a GC, the programmer is personally responsible for deciding exactly when a piece of allocated memory is no longer needed and calling a function to release it. This sounds simple in principle, but at real-world scale it's one of the largest sources of serious bugs in software history:

• Memory leaks — an object is allocated, becomes unreachable, but nothing ever calls free() on it. The memory is gone for the life of the process. A long-running server leaking memory on every request will eventually run out of memory and crash.
• Use-after-free — code frees memory, but another piece of code (or the same code, later) still holds a pointer to it and uses it anyway. The memory might now belong to something else entirely, leading to silent data corruption or a crash — and historically, a huge source of security vulnerabilities.
• Double-free — the same block of memory gets freed twice. This corrupts the allocator's internal bookkeeping and can cause crashes or exploitable memory corruption far away from the actual bug.

These bugs are notoriously hard to find because the symptom (a crash, or corrupted data) often shows up long after and far away from the actual mistake (the missing or extra free() call).

The Solution

The GC removes the decision of "when to free this" from the programmer entirely. You simply stop using an object — by letting the last reference to it go out of scope, or setting it to null, or letting a containing object become unreachable — and the GC figures out, safely and automatically, when it's truly gone for good. Because it only ever reclaims objects that are provably unreachable from any root, use-after-free and double-free bugs on managed memory are structurally eliminated, not just made less likely. Memory leaks are still possible in .NET (if something keeps an unwanted reference alive), but the entire class of "freed too early" or "freed twice" bugs simply cannot happen through ordinary managed code.

Big Picture

How It Works

Step 1 — Objects are allocated, and become reachable via a root

void ProcessOrder()
{
    var order = new Order(); // 'order' (a local var) is a root — Order object is reachable
    order.Items.Add(new OrderItem("Widget", 3)); // reachable via order.Items
}

While ProcessOrder is executing, order is a local variable on the stack — a GC root. The Order object it points to is reachable, and so is the OrderItem reachable through order.Items.

Step 2 — The method returns; the root disappears

Once ProcessOrder returns, the local variable order ceases to exist — it's no longer a root. If nothing else in the program still holds a reference to that Order object (say, it wasn't saved anywhere, and no event handler captured it), the object — and everything reachable only through it — is now unreachable.

Step 3 — A collection happens, triggered by allocation pressure

The GC does not run on a fixed timer, and it does not run the instant an object becomes unreachable. It runs when the runtime decides memory pressure warrants it — most commonly, when a generation of the heap (covered in the next lesson) has accumulated enough new allocations to be worth examining. This is a deliberately non-deterministic point in time from your code's perspective: you cannot reliably predict exactly when a given unreachable object's memory will actually be reclaimed.

Step 4 — The GC traces from roots and identifies survivors

When a collection runs, the GC (conceptually) walks the object graph starting at every current root, marking every object it finds along the way as "still alive." This is the mark phase of a mark-and-sweep-style approach: mark what's reachable, then treat everything unmarked as reclaimable.

Step 5 — Unreachable memory is reclaimed, and live memory is often compacted

Objects with no path back to any root are garbage — their memory is freed. .NET's GC typically also compacts the surviving objects (moves them together, eliminating gaps left by the reclaimed ones), which keeps future allocation fast and avoids fragmentation. You'll see exactly why compaction matters for allocation speed in the memory allocation lesson later in this module.

Simple Example

public class Report
{
    public string Title { get; set; } = "";
}

Report CreateReport()
{
    var report = new Report { Title = "Q3 Summary" }; // allocated on the heap
    return report;
}

void RunReport()
{
    var r = CreateReport(); // r now holds the only reference
    Console.WriteLine(r.Title);
    // r goes out of scope here when RunReport returns
    // From this point on, the Report object is unreachable
    // — eventually, a GC will reclaim it. Exactly when is not
    //   something your code can rely on or observe directly.
}

Code → Meaning → Result:

• Inside CreateReport, the new Report is reachable through the local variable report, and then through the returned reference stored in r.
• Once RunReport returns, r no longer exists as a root, and (assuming nothing else references it) the Report object becomes garbage.
• Nothing in this code explicitly frees anything — that's the entire point. The GC will reclaim it on some future collection, whenever memory pressure makes that worthwhile.

Real-World Example

Consider an ASP.NET Core API handling thousands of requests per minute. Every request typically allocates a burst of short-lived objects: a request DTO, a few EF Core entity instances, a result object, maybe some LINQ intermediate collections. Once the response is written and the request completes, every one of those objects instantly becomes unreachable — nothing in the app still references them.

Over the life of the process, this produces an enormous, continuous churn of allocate-then-discard. The GC is what makes this workable at all: without it, the server would need to explicitly track and free every one of those thousands of small, per-request objects, correctly, every single time, with zero mistakes — an essentially impossible bar to hold in a codebase with any real complexity. The GC instead lets developers focus entirely on business logic, while it continuously reclaims the constant stream of request-scoped garbage in the background.

This also explains why .NET provides concurrent (background) GC as the default mode for server workloads: a request-serving process cannot tolerate the entire application freezing for a long pause every time memory needs reclaiming, so much of the GC's work happens on a background thread, concurrently with your application continuing to run.

Analogy

Under the Hood

Common Confusion

1. "The GC frees memory the instant an object goes out of scope"

It doesn't. Going out of scope (or setting a reference to null) makes an object eligible for collection — it removes the object from the reachable set. But the actual reclamation only happens the next time a collection runs against the generation that object lives in, which could be milliseconds later or, if memory pressure is low, considerably longer. Reachability and reclamation are two separate events.

2. "The .NET GC uses reference counting, like some other languages"

No — .NET's GC is a tracing collector, not a reference-counting one. Reference counting (incrementing/decrementing a counter on every assignment) has its own well-known weakness: two objects that reference each other, but that nothing else references, would keep each other's count above zero forever under naive reference counting — a reference cycle that leaks. A tracing collector like .NET's has no such problem: if neither object is reachable from an actual root, both are correctly identified as garbage, cycle or not.

3. "Garbage collection means .NET can't leak memory"

The GC eliminates use-after-free and double-free bugs, but it cannot eliminate leaks caused by your own code accidentally keeping something reachable forever — a static collection you keep adding to and never clear, an event subscription that's never unsubscribed, a cache with no eviction policy. If a root still points to it, directly or transitively, the GC is doing exactly its job by keeping it alive. "Managed memory leak" is a real, common category of production bug — it just has a different root cause than in unmanaged languages.

Common Mistakes

Mistake 1 — Calling GC.Collect() manually "to be safe"

Sprinkling GC.Collect() throughout application code on the assumption it will improve performance or memory usage.

In almost every real scenario, this makes things worse: it forces a full, synchronous collection at a moment the runtime's own heuristics would not have chosen, interrupting work that was proceeding fine. Trust the GC's own scheduling; it has far more information about actual memory pressure than a single call site does.

Mistake 2 — Assuming an object is gone just because you set the variable to null

Writing myObject = null; and treating that as equivalent to memory being immediately freed.

Setting a reference to null removes one path to the object — it makes the object unreachable if that was the only path. The memory itself is reclaimed later, whenever a collection actually runs. For deterministic, immediate resource cleanup (file handles, network sockets), C#'s IDisposable/using pattern — which you already learned in earlier tiers — is the correct tool, not relying on GC timing.

Mistake 3 — Diagnosing "memory keeps growing" as a GC bug rather than a rooted reference

Assuming rising memory usage means the garbage collector "isn't working" or is somehow broken.

Almost always, growing managed memory means something is still reachable that you didn't intend to keep alive — a forgotten event subscription, an ever-growing static cache, a captured closure holding a reference longer than expected. The fix is finding and breaking that reference chain, not distrusting the GC itself.

Why Does This Matter for My Code?

You can't turn the GC off for ordinary managed objects, and you almost never should try to. What this lesson changes is how you reason about memory-related symptoms:

• When memory grows unexpectedly, you now know to ask "what's still rooting this?" rather than "why isn't the GC running?"
• When you see occasional latency spikes in a server app, you know to consider GC pauses as one real, legitimate hypothesis — and you know concurrent GC exists specifically to minimize (not eliminate) that class of spike.
• You understand precisely why IDisposable exists alongside the GC: the GC handles memory, but it has no idea a file handle or network connection needs to be released promptly — that's still your explicit responsibility.
• The next lesson builds directly on this one: you'll learn why .NET doesn't trace the entire heap on every collection, and how "most objects die young" shapes the GC's whole design.

Mental Model

Key Takeaway

Check Your Understanding

You've learned what the GC is, why it exists, and how it decides what's garbage. Let's test the core mental model.

You now understand why the GC exists and how it decides what's safe to reclaim — next, you'll see how .NET makes this fast in practice with generations.