Garbage Collection in C#: How .NET Cleans Up After You 🧹
If you’ve ever written C#, you’ve already used one of its most powerful features — whether you realized it or not. Every time you new up an object, C# quietly handles the messy job of memory management for you.
You don’t have to free() anything, you don’t have to track pointers, and you never have to worry about segmentation faults.
That’s thanks to the .NET Garbage Collector (GC) — one of the unsung heroes of the runtime.
But while C# developers get to ignore memory most of the time, understanding how the garbage collector works is one of those “grown-up” moments in your coding journey. It’s where you stop writing code that runs, and start writing code that runs efficiently.
🧠 What Garbage Collection Actually Is
When you create an object in C# like this:
Using memory from the managed heap
That object gets allocated in memory — specifically on the managed heap, a section of memory controlled by the CLR (Common Language Runtime).
Every allocation adds data to this heap, and the runtime keeps track of what’s still being used and what’s not.
Once something no longer has any references pointing to it — meaning nothing in your code can reach it — it becomes eligible for collection.
Then, the garbage collector eventually swoops in, reclaims that memory, and makes it available for new allocations.
🗑️ In short:
You create objects.
The CLR tracks references to them.
When there are no references left, GC frees the memory.
You get automatic memory management with minimal effort.
It’s a simple idea — but the way the .NET GC pulls it off is surprisingly sophisticated.
⚙️ How the .NET Garbage Collector Works
The .NET GC isn’t just one big cleanup thread. It’s a generational, compacting, mark-and-sweep garbage collector.
Let’s unpack that — because each of those terms matters.
1. Generational Collection
Not all objects live the same amount of time.
Some are short-lived — like strings built inside a loop (local scope).
Others are long-lived — like singletons, caches, or static configuration.
To optimize for this, the .NET GC organizes memory into three generations:
The 3 generations of garbage collection
When a garbage collection occurs, it usually only checks Gen 0.
That means the GC can clean up frequently and quickly, without scanning the entire heap every time.
Objects that survive a cleanup get promoted to the next generation, where they’re checked less often.
✅ Why this matters:
This tiered system makes GC extremely efficient — short-lived junk gets cleaned fast, while long-term data doesn’t keep slowing things down.
2. Mark and Sweep
The GC doesn’t just delete random objects — it has to know what’s still in use.
Here’s how it figures that out:
Mark Phase:
The “mark” phase begins by identifying a set of objects called root references — these are the starting points that are always considered alive. Root references include:Local variables currently in use by methods on the stack.
Static fields on classes.
CPU registers that hold object references.
Objects pinned for interop (e.g., when passing managed data to unmanaged code).
From these roots, the GC performs a kind of graph traversal through all referenced objects — following every field, property, or array element that points to another object. An object is considered reachable if it can be traced, directly or indirectly, from one of these root references. If there’s a path from a root to the object, it’s alive. If no path exists — meaning no variable, field, or structure anywhere in your program can reach it — the GC marks it as unreachable and prepares to collect it in the next sweep.
You can picture it like shining a flashlight from your program’s “entry points.” Every object the light touches is kept; everything left in the dark is garbage.
Sweep Phase:
Anything not marked gets flagged as garbage and reclaimed.
That’s why if you lose all references to an object (by setting them to null, or letting them fall out of scope), the GC can safely free that memory.
3. Compaction
After garbage is swept away, the memory left behind has gaps. To avoid fragmentation, the GC compacts the heap — moving live objects together and updating references. This makes future allocations faster because the heap stays contiguous.
Think of it like cleaning a messy drawer: you throw out the junk, then push the remaining stuff to one side so there’s space for new items.
Why C# Uses a Managed Heap
In lower-level languages like C or C++, developers have to manually allocate and free memory. That’s flexible but error-prone. C# and .NET take the opposite approach: you trade a little control for a lot of safety.
The managed heap lets the runtime:
Automatically detect when memory is safe to free.
Prevent use-after-free and dangling pointer bugs.
Optimize allocation speed (heap allocations are extremely fast in .NET).
Compact memory automatically to avoid fragmentation.
You can think of it as automatic memory insurance — you pay a tiny performance premium, but you never lose your data to a bad pointer dereference.
When Garbage Collection Happens
Garbage collection doesn’t happen at random — the CLR triggers it based on memory pressure and allocation patterns.
Here are the main triggers:
Gen 0 fills up — most common.
The system runs low on memory.
You call
GC.Collect()manually (not recommended).The app goes idle — background GC runs opportunistically.
Normally, you should never call GC.Collect() yourself — the runtime is almost always better at timing collections than you are.
The Managed Heap in Action
Let’s visualize it:
You allocate three objects. They go into Gen 0.
The GC runs and finds that two are no longer referenced.
Those get deleted, and the surviving one gets promoted to Gen 1.
You allocate more objects; eventually, Gen 0 fills up again.
GC runs again, and the cycle continues.
In a large application, most collections happen in Gen 0 and complete in milliseconds — you usually don’t even notice.
Server vs. Workstation GC
The .NET runtime provides two GC modes, tuned for different environments:
Two different kinds of garbage collection, tailored to their desired performance
You can control this via your project’s .config file or runtime settings.
If you’re building Unity games or desktop tools, you’re on Workstation GC. If you’re running ASP.NET or backend services, you’re using Server GC for performance.
Large Object Heap (LOH)
Objects larger than 85 KB don’t go into the regular heap — they go into a special area called the Large Object Heap (LOH).
Why? Because moving big blocks of memory during compaction is expensive.
The LOH skips compaction to avoid that cost — but that also means it can fragment over time.
If your app allocates and frees lots of large objects (like big byte arrays or image buffers), you may eventually hit performance hiccups due to fragmentation.
Memory Leaks in a Managed Language?
Wait — if C# manages memory for you, how can you still leak memory? It’s not about freeing; it’s about references.
If you accidentally keep references to objects you no longer need, the GC sees them as “in use” and won’t collect them.
Common causes:
Static fields holding onto objects.
Events not unsubscribed (
+=without-=).Caches or lists that never clear.
Long-lived objects referencing short-lived ones.
Garbage collection doesn’t save you from poor reference management — it just automates when memory is freed.
⚠️ Common GC Misconceptions
❌ “Garbage collection slows down my program.”
Not necessarily. Modern GC is extremely efficient — and it often improves performance by compacting memory and preventing fragmentation.
❌ “GC runs constantly.”
Nope. It runs only when needed — typically when Gen 0 fills up.
❌ “You should always call GC.Collect() manually.”
Almost never. The runtime has decades of tuning behind its heuristics — trust it unless you have a very specific edge case.
How to Work With the Garbage Collector
Here are a few practical tips that make a big difference:
✅ 1. Minimize Unnecessary Allocations
Avoid creating objects in tight loops or per-frame in Unity. Instead, reuse objects (object pooling) or use structs for small, short-lived data.
✅ 2. Use using and IDisposable
Garbage collection frees memory, but not unmanaged resources (like file handles, sockets, or GPU memory). The using keyword ensures those get cleaned up properly:
Not all resources are managed for you, so be careful
✅ 3. Be Mindful of Events
Unsubscribed event handlers are one of the top causes of memory leaks in .NET. Always pair += with -= when appropriate.
✅ 4. Avoid Holding Unnecessary References
Set large collections to null when done, or use weak references for caches.
✅ 5. Use Value Types When Possible
Small structs stored on the stack don’t need GC cleanup at all — they’re removed automatically when they go out of scope.
Advanced Tip: Weak References
If you want to reference an object without preventing it from being collected, use a WeakReference<T>.
Example:
The weak reference won’t save it from the garbage collector
This allows the GC to reclaim that object if memory is tight — perfect for image or asset caches.
Observing the GC in Action
You can monitor garbage collection using the Performance Profiler in Visual Studio, dotMemory, or Unity’s Profiler window.
Watch for:
GC Allocations per frame
Collection frequency
Heap size growth over time
If you see frequent full (Gen 2) collections or excessive LOH growth, you’re allocating too aggressively.
The Big Picture
C#’s garbage collector is one of the reasons .NET apps are so stable. It handles millions of allocations per second, keeps your heap compact, and does all of it in the background.
But while it’s automatic, it’s not invisible. When you understand how it works, you stop fighting the runtime and start writing code that flows with it.
🧠 TL;DR
Garbage collection automatically reclaims unused memory in .NET.
It works in generations for speed and efficiency.
Large objects go to the LOH, which can fragment.
Memory leaks still happen if you hold onto references.
Don’t call
GC.Collect()— let the runtime handle it.Profile allocations, use structs smartly, and dispose of unmanaged resources.
Garbage collection isn’t just about freeing memory — it’s about keeping your programs fast, safe, and clean without breaking your flow as a developer.
So next time you hit “Run,” take a moment to appreciate the silent janitor cleaning up behind your code.