Everything That Every .NET Developer Needs to Know About Disposable Types: Properly Disposing Objects

Microsoft .NET has been around for 20 years and one thing that is very critical for every to know is exactly how memory management works in the runtime. If you don’t, you will cause performance issues but more serious is causing virtual memory leaks. The way that .NET was designed back in the late ’90s is that it does not have memory leaks in the true sense, but it can create virtual memory leaks.

This article covers the way to dispose of objects properly for most cases. There are edge cases where Dispose should not be called due to the lifetime of the object. That will be covered in a separate article.

In a nutshell, if your app has a virtual memory leak, the memory is not destroyed correctly properly, and the leak just keeps building up until the app or service crashes. I have even seen it bring down servers on the backend (I have written about this many times before, so I won’t re-tell them here) and in client apps.

The reason I decided to write a comprehensive set of articles about reference types that implement IDisposable and where you might need to in your types is because of a recent solution I worked on. Unfortunately, this solution has the most issues of any of the millions of lines of code I have analyzed in the past 20 years. I had hoped that after all this time, developers would know how to do this correctly, but sadly it is obvious to me far too many do not, so I hope these articles will help this critical issue.

This solution has a little over a million lines of code. First, I found over 600 places in the code where Dispose() is not being called on Disposable types. Also, I found over 90 types that either did not implement IDisposable correctly or did not implement it when it needed to. For the classes that did implement IDisposable, not even one did it correctly. These changes will cause over 2,000 touchpoints in the code that will need to be changed, code reviewed, tested, and deployed.

The reason I’m sharing these real-world numbers is that if developers do not deal with these types when the code is first written, it will be very, very expensive and time-consuming to fix later down the road (if they even get fixed). Far too many teams do not understand why they must restart servers or services on a regular basis… this is the reason! Please use these articles as a warning for your team and management!

New Code Rules

I feel so strongly about this I made it the topic of a recent New Code Rules segment on my show Rockin’ the Code World with dotNetDave on C# Corner Live. I rant in this video but also give ideas for Microsoft to once and for all solve this issue so developers do not need to worry about it and so apps and services stop failing.

Two Types of Memory Management in .NET

Microsoft .NET handles memory in two very different ways that every developer needs to fully understand. The first is the memory stack where all value types are created. The second is the memory heap where all reference types are created and managed by the garbage collector, and this will be the focus of this article. How do you know if a type is a value or reference type? It’s fairly easy… all types such as DateTime, integer, Boolean, or any of the framework types that are number-based, plus user-defined types (structures), are value types and live on the memory stack. Everything else, including the classes you create, are reference types and live on the memory heap. Essentially if you create a type by using ‘new’, it’s a reference type, including the string type. Reference types are what need attention, especially if they implement IDisposable or contain any disposable fields.

The Memory Heap

People have been writing about how the memory heap works in .NET since it was released, so I won’t rehash that here since that would be an article (or an eBook) in of itself. If you are new to .NET or don’t fully understand how the memory heap and the Garbage Collector works, go here for more detailed information from Microsoft https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/fundamentals.

I will quickly mention that the reason .NET is very performant is that when objects are created on the heap, they are always created at the top of the heap. When an object is no longer is used, it is marked to be removed from memory by the Garbage Collector (GC). They do not go away at the end of the code block! Then the heap is compacted by the GC. When are they are removed from memory?

Whenever the Garbage Collector wants to!

Well, it’s a lot more complicated than that, but just remember, developers have no real direct control over the GC. All we can do is allocate cautiously, release objects as soon as possible, and most importantly call Dispose on any disposable objects or implement IDisposable for the types we create that contain a field that is a disposable type. In the early days of .NET, I spent a lot of time watching and learning how the GC works, so I understand it well. Also, twice I had one of the engineers who created the GC speak at the user group I ran for 20 years. Listening to him and speaking with him taught me even more about how memory works in .NET and the pitfalls of the GC.

Disposing Disposable Types

First, let us get into what I teach my beginner students when I taught at a university.

It is critically important to call Dispose() on any type that implements IDisposable!

If a type implements IDisposable it means that it has something it needs to clean up like file handles, memory pointers, other disposable types, and more. So, developers MUST call Dispose as soon as the object is done being used. How do you know if a type implements IDisposable? There are two simple ways.

The first is, just type “.Dispose” at the end of the variable for the type, if it comes up in Intellisense, then you need to call it. The other method is to right mouse click on the type and select ‘Go to Definition’ and see if IDisposable is in the definition of the class. This is exactly what I tell my beginner students. After you deal with disposable types for a while, you will start to remember which ones are. Here are some helpful tips that I use when I first analyze a codebase.

  1. If the type name ends in “Stream”, it’s disposable.
  2. If the type name ends in “Writer” or “Reader”, it’s most likely disposable.
  3. Any types that deal with graphics are most likely disposable such as the Bitmap type.
  4. If the type deals with connections, such as databases, sockets, HTTP, it’s disposable. This also includes related types such as DataTable, MailMessage, HttpWebResponse, and more.
  5. Hash algorithms, such as MD5, SHA, RSA and more.

How we dispose of disposable objects has changed since .NET was created. The safest, recommended way is by using the using pattern and statement.

Here is how to properly use the using statement pattern (the code below is from my OSS called Spargine).

public static TResult Deserialize<TResult>(string xml) where TResult : class
{
     using (var sr = new StringReader(xml))
     {
          var xs = new XmlSerializer(typeof(TResult));

          return (TResult)xs.Deserialize(sr);
     }
}

First, the Disposable object is created in the using statement. When the end of that code block is reached, then Dispose will be called by the runtime. What happens is that the compiler creates a try/finally block and calls Dispose in the finally as shown in the IL code below.

Hidden Dispose Issues-2

You can also use the simple using statement as shown below:

using var sr = new StringReader(xml);

var xs = new XmlSerializer(typeof(TResult));

return (TResult)xs.Deserialize(sr);

Both using statements do the same thing, but I tend to prefer the original using statement since for me as a code reviewer, it’s easier for me to spot where it’s being used or isn’t being used.

Hidden Disposable Issues

Other “hidden” disposable issues also need to be considered. Some developers who like to put as much code on one line could run into issues. Go to this article to learn about these hidden issues: https://dotnettips.wordpress.com/2021/10/06/hidden-idisposable-issues-in-microsoft-net/

Summary

The takeaway from this article is that it is critically important to make sure all your code is properly disposing of disposable types. Not only could this improve the performance of your apps, but more importantly your apps will be free of virtual memory leaks.

I challenge everyone reading this article to do a critical scan of your codebase NOW to ensure that all your disposable types are being disposed of. I would love to hear how many of these issues you found. Just comment below.

Part 2 of this article will tackle how to properly implement the IDisposable interface for types that you create that have field variables that hold disposable types.

Don’t forget to learn all about code performance for Microsoft .NET by going to the Code & App Performance Page: https://bit.ly/CodeAppPerformance.

I hope you will support this site by buying dotNetDave a cup of coffee (he works really hard on these articles): https://www.buymeacoffee.com/dotnetdave

3 thoughts on “Everything That Every .NET Developer Needs to Know About Disposable Types: Properly Disposing Objects

  1. Going to disagree strongly…. Consider what I consider to be a very strong anti-pattern…

    public void Cleanup() { /* do things that do NOT involve unmanaged resources */ }

    The above is good… but then…someone adds IDisposable and

    public void Dispose() {Cleanup(); }

    Still NO managed resources in sight. Just be a responsible developer and ensure (usually with a finally block) that Clenup is called…

    Rmember Dispose does NOTHING about “freeing” managed memory. When the GC runs is something is “Reachable” then it gets COPIED from Gen0 to Gen1 then to Gen2 [ LArge Objects are different]. If something is Gen2 is MODIFIED then a block of memory is marked as “we dont know what is reachabel here, scan this memory range on next level 2…

    So… (assuming no finalizer, no unmanaged code…

    class A { private B m_B = new B(); }
    class B { private C m_C = new C(); }

    Then var x = new A () // which creates B and C… Assuming no other reference, as soon as X goes out of scope (or sooner if optimized, to last actual usage) then A,B,C are no longer reachable. If this hapens before a GC, then they are still in Gen0 – so not copied to Gen1 – they simply wink out of existance….

    NO amount of adding IDisposable will change this.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.