Why you need to understand garbage collection

I’ve been interviewing lots of C# developers recently, and one of my stock questions is “how does the .NET garbage collector know when you’ve finished using an object?” The reason I ask is this because having an understanding of the underlying workings of .NET such as the garbage collector generally indicates that the candidate is a good developer. It shows that they care about how the tools and technologies they are using actually work, and this enables them to write better code.

However, I have been surprised at how many .NET developers, even ones who give good answers to other technical questions, really seem to struggle with this topic. This is particularly noticeable with younger C# developers – those who have only used garbage collected languages in their entire career.

I have a theory as to why this is: when older developers who got started in C/C++ started to try out garbage collected languages like C# and Java, we were initially very suspicious. Freeing memory was such a critical part of how we were used to writing code, that we wanted to know exactly how the garbage collector knew what to collect, when it would run, and we even wanted to take control ourselves and force it to run on demand.

But people who have only ever programmed with garbage collected languages have not been scarred by the horrors of debugging memory leaks, or dereferencing pointers to already freed memory. And so there isn’t such a strong incentive to delve into the inner workings of the garbage collector.

This is unfortunate, as having a solid understanding of the garbage collector is extremely useful when trying to write high performing code. It can be particularly valuable in applications like digital audio, where you are working at low latencies in real-time, and even a small delay due to the garbage collection could cause a glitch in playback. You learn techniques such as reusing byte arrays rather than repeatedly creating new ones, in order to minimise the amount of work the garbage collector needs to do. It will also help you understand why certain objects need to be “pinned” to allow you to use them in conjunction with unmanaged code.

So if you’re a C# developer and you don’t yet have a good understanding of what the garbage collector is and how it works, why not do yourself a favour and educate yourself a bit? It won’t take a huge amount of time, and there are plenty of good articles on the subject. And if you’ve got a Pluralsight subscription (which I highly recommend!), then my friend Elton has a whole module explaining the garbage collector in his IDisposable best practices course.