Proper Use of IDisposable in C#: Managed vs Unmanaged Resources

By the end of this page, you will understand what IDisposable is actually for in C#, when it should be implemented, and why calling Dispose() does not force the garbage collector to free managed memory immediately. You will also learn the difference between cleaning up unmanaged resources and simply dropping references to managed objects.

IDisposable is a C# pattern for deterministic cleanup. That means it gives your code a way to release resources at a known time instead of waiting for the garbage collector.

The most important point is this:

• Garbage collection manages memory for managed objects
• Dispose() is mainly for releasing resources that the garbage collector does not manage well or quickly enough

What kinds of resources usually need Dispose()?

These are the common examples:

• File handles
• Database connections
• Network sockets
• Window handles
• Streams
• Timers
• Native memory allocated outside the CLR

These resources are limited and often tied to the operating system. Even if the memory for the C# object is managed, the underlying resource may still need explicit cleanup.

Why not use Dispose() just to clear normal fields?

In your example, _theList and _theDict are managed objects. The garbage collector already knows how to reclaim them when nothing references them anymore.

Doing this inside Dispose():

_theList.Clear();
_theDict.Clear();
_theList = null;
_theDict = null;

does not immediately free their memory. It only removes references from the current object. The actual memory is reclaimed later, when the garbage collector runs and confirms that those objects are no longer reachable.

Important distinction: releasing a resource vs reclaiming memory

Dispose() can:

• close a file now
• release a database connection now
• stop a timer now
• unsubscribe from events now

But Dispose() cannot directly tell the garbage collector:

• "free this managed memory immediately"

The GC decides when managed memory is reclaimed.

Why do some classes dispose managed objects?

Sometimes a class owns other objects that themselves implement IDisposable. In that case, your class should often dispose them too.

Example:

public class ReportWriter : IDisposable
{
    private StreamWriter _writer;

    public ReportWriter(string path)
    {
        _writer = new StreamWriter(path);
    }

    public void Dispose()
    {
        _writer?.Dispose();
    }
}

Here, _writer is a managed object, but it wraps an unmanaged resource: a file handle. Disposing it is meaningful.

What about a huge list with one million strings?

If you clear the list or set the field to null, you may make those objects eligible for garbage collection, but you do not free the memory immediately.

That means:

• Clear() removes references from the list to its elements
• null removes your field reference to the list itself
• the objects become collectible only if no other references exist
• actual memory is reclaimed later, when the GC runs

So the code can make memory eligible for cleanup sooner, but it does not guarantee immediate release.

When should you implement IDisposable?

Usually when your class:

• directly owns unmanaged resources, or
• owns disposable objects whose lifetime should end predictably, or
• needs explicit cleanup beyond memory reclamation, such as event unsubscription or stopping background work

If your class only contains ordinary managed collections like List<T> and Dictionary<TKey, TValue>, implementing IDisposable is usually unnecessary.

Think of the garbage collector as the building's cleanup staff. It walks through rooms periodically and removes items that nobody is using anymore.

Dispose() is different: it is like returning a borrowed keycard, closing a water valve, or hanging up a phone call right now.

• A List<string> is like a pile of paper in your office. If nobody can reach it anymore, cleanup staff will remove it later.
• A file handle or database connection is like a borrowed hotel room key. You should return it as soon as you are done.

So:

• GC handles unused managed memory eventually
• Dispose() handles important cleanup immediately when needed

Clearing references in Dispose() is like putting a note on the pile that says, "This can be thrown away." It does not mean the cleanup staff instantly arrives.

Basic IDisposable syntax

public class MyResource : IDisposable
{
    private bool _disposed;

    public void Dispose()
    {
        if (_disposed) return;

        // Release owned disposable resources here
        _disposed = true;
    }
}

This pattern is useful when the class actually owns something that needs explicit cleanup.

Example: disposing a managed wrapper around an unmanaged resource

using System;
using System.IO;

public class FileLogger : IDisposable
{
    private StreamWriter _writer;
    private bool _disposed;

    public FileLogger(string path)
    {
        _writer = new StreamWriter(path);
    }

    public void Log(string message)
    {
        if (_disposed)
            throw new ObjectDisposedException(nameof(FileLogger));

        _writer.WriteLine(message);
    }

    public void Dispose()
    {
        if (_disposed) return;

        _writer?.Dispose();
        _writer = null;
        _disposed = true;
    }
}

Why this makes sense

• StreamWriter is managed, but it owns a file resource underneath.
• Calling Dispose() closes the file promptly.
• This is a correct and useful reason to implement IDisposable.

Example: class that should usually not implement IDisposable

using System.Collections.Generic;
using System.Drawing;

public class MyCollection
{
    private List<string> _theList = new List<string>();
    private Dictionary<string, Point> _theDict = new Dictionary<string, Point>();
}

This class only stores normal managed objects. There is nothing here that requires deterministic cleanup.

Using using

A common way to work with IDisposable is the using statement:

using (var writer = new StreamWriter("log.txt"))
{
    writer.WriteLine("Hello");
}

This ensures Dispose() is called automatically at the end of the block.

Consider this example:

List<string> items = new List<string>();
items.Add(new string('A', 1000));
items.Add(new string('B', 1000));
items = null;

What happens step by step?

1. items is created and points to a List<string> object on the managed heap.
2. Two large strings are created and stored inside the list.
3. items = null; removes your local variable's reference to the list.
4. If there are no other references to that list or its strings, they become eligible for garbage collection.
5. The memory is not necessarily reclaimed immediately.
6. Later, when the garbage collector runs, it can reclaim that memory.

Now compare with Dispose() that clears fields

public void Dispose()
{
    _theList.Clear();
    _theDict.Clear();
    _theList = null;
    _theDict = null;
}

Step by step

1. Clear() removes references from the collections to their contained items.
2. Setting the fields to null removes this object's references to the collections.
3. If nothing else references those collections or items, they become collectible.
4. The garbage collector still chooses when memory is actually reclaimed.

Key result

This may reduce how long objects stay reachable, but it does not force immediate memory release.

When IDisposable is used in real applications

File and stream handling

using var stream = File.OpenRead("data.txt");

Why: file handles are limited and should be closed promptly.

Database access

using var connection = new SqlConnection(connectionString);
connection.Open();

Why: connections are expensive and usually come from a pool. Disposing returns them quickly.

HTTP and network resources

Sockets, streams, and response objects often need deterministic cleanup to avoid resource leaks.

UI and graphics resources

Types such as Bitmap, Graphics, and some UI handles wrap native resources and should be disposed.

Event subscriptions and background work

A class may implement IDisposable to unsubscribe from events or stop timers/tasks when it is no longer needed.

When it is usually not needed

• Plain data containers
• Value objects
• Classes that only hold strings, lists, dictionaries, and numbers
• DTOs and configuration objects

These rely on normal garbage collection.

In production code, IDisposable is commonly used with clear ownership rules.

Common patterns

1. Owning a disposable dependency

If your class creates and owns an object like StreamWriter, it should usually dispose it.

public class ExportService : IDisposable
{
    private readonly StreamWriter _writer;

    public ExportService(string path)
    {
        _writer = new StreamWriter(path);
    }

    public void Dispose()
    {
        _writer.Dispose();
    }
}

2. Guard clause after disposal

Developers often prevent use-after-dispose bugs.

private bool _disposed;

private void ThrowIfDisposed()
{
    if (_disposed)
        throw new ObjectDisposedException(nameof(ExportService));
}

3. Early release of scarce resources

Even though memory is managed, connections and file handles should be released as soon as possible.

4. Unsubscribing from events

public void Dispose()
{
    _publisher.SomeEvent -= OnSomeEvent;
}

This is useful because event subscriptions can keep objects alive longer than expected.

5. Using using and using var

Instead of manually calling Dispose(), many codebases prefer scoped disposal:

using var reader = new StreamReader(path);
var content = reader.ReadToEnd();

What teams usually avoid

• Adding IDisposable to every class by default
• Clearing ordinary collections in Dispose() without a real need
• Assuming Dispose() is a manual garbage collection API

That last misunderstanding is exactly what your example highlights.

1. Using Dispose() to manage normal memory

Broken idea

public void Dispose()
{
    _list = null;
}

This does not free memory immediately. It only removes a reference.

Better understanding

• It may help objects become unreachable sooner.
• The garbage collector still decides when memory is reclaimed.

2. Implementing IDisposable when nothing needs disposing

Unnecessary code

public class Person : IDisposable
{
    public string Name { get; set; }

    public void Dispose()
    {
    }
}

If the class has no unmanaged resources and owns no disposable dependencies, this adds complexity for no benefit.

3. Forgetting to dispose owned disposable objects

Broken code

public class ReportWriter : IDisposable
{
    private StreamWriter _writer = new StreamWriter("report.txt");

    public void Dispose()
    {
        // forgot to dispose _writer
    }
}

Fix

public void Dispose()
{
    _writer?.Dispose();
}

4. Using an object after disposal

Broken code

logger.Dispose();
logger.Log("still using it");

This can cause errors or undefined behavior.

Fix

Track disposal state and throw ObjectDisposedException when needed.

5. Thinking Clear() releases all memory immediately

Clear() removes elements from a collection, but it does not guarantee that the collection's internal storage shrinks right away.

For example, a list may keep its internal capacity for reuse.

6. Calling GC.Collect() to force cleanup

Beginners sometimes try this:

GC.Collect();

Usually this is a bad idea. It can hurt performance and should not be used as normal memory management.

Dispose() vs finalizer

Dispose() vs just letting GC work

Quick rules

• Implement IDisposable when your class:
  • owns unmanaged resources, or
  • owns disposable objects, or
  • needs deterministic cleanup such as event unsubscription
• Do not implement IDisposable just because a class has fields.
• Dispose() does not force immediate garbage collection.
• Setting fields to null only removes references.
• Clear() removes items from a collection but does not guarantee memory is returned immediately.

Basic pattern

public class MyType : IDisposable
{
    private bool _disposed;
    private SomeDisposableType _resource;

    public void Dispose()
    {
        if (_disposed) return;
        _resource?.Dispose();
        _disposed = true;
    }
}

Use with using

using var stream = File.OpenRead(path);

Key idea

• Managed memory -> cleaned by GC
• External/scarce resources -> often cleaned by Dispose()

Your example

_theList.Clear();
_theList = null;

This can make objects collectible sooner, but it does not free memory instantly.

When should I implement IDisposable in C#?

Implement it when your class owns unmanaged resources, owns disposable objects, or needs explicit cleanup such as unsubscribing from events.

Does Dispose() free managed memory immediately?

No. It only runs your cleanup code. Managed memory is still reclaimed by the garbage collector at a time chosen by the runtime.

Does setting a list field to null release its memory?

Not immediately. It removes one reference. If no references remain, the object becomes eligible for garbage collection.

Does List<T>.Clear() return memory to the system?

Not necessarily. It removes elements, but the list may keep internal capacity allocated for future use.

Why do managed classes like StreamWriter implement IDisposable?

Because they often wrap unmanaged resources such as file handles, sockets, or OS objects.

Should every class with fields implement IDisposable?

No. Most classes should not. Only implement it when deterministic cleanup is actually needed.

Can I call GC.Collect() after Dispose() to free memory faster?

You can, but you usually should not. It often hurts performance and is rarely the right solution.

If my class contains one million strings, can Dispose() guarantee instant memory release?

No. It can remove references so the strings become collectible sooner, but the GC still decides when to reclaim the memory.

• using statement — The most common way to ensure Dispose() is called automatically.
• Garbage collection — Helps explain why managed memory is not freed immediately.
• Finalizers — Related as a fallback cleanup mechanism for unmanaged resources.
• Object lifetime — Important for understanding reachability and when objects can be collected.
• Resource management — The broader topic that includes files, connections, handles, and cleanup.
• IAsyncDisposable — Modern async version of deterministic cleanup for asynchronous resources.
• Event subscriptions — Relevant because events can keep objects alive and may need explicit unsubscription.
• Collection capacity — Helps explain why Clear() does not always reduce memory usage immediately.