IDisposable, using, and what the GC does not do

What the garbage collector handles

.NET memory is managed: objects are allocated on the heap and the garbage collector (GC) reclaims the ones nothing references any more. It is generational, built on the observation that most objects die young:

• New objects start in generation 0, which is collected often and cheaply.
• An object that survives a collection is promoted, to gen 1 and then gen 2, which are collected less often.
• Objects of 85,000 bytes or more go on the large object heap, which is collected together with gen 2.

1public static class Solution2{3    public static string Describe()4    {5        var survivor = new byte[100];6        var gens = new List<int> { GC.GetGeneration(survivor) };7        GC.Collect();8        gens.Add(GC.GetGeneration(survivor));9        GC.Collect();10        gens.Add(GC.GetGeneration(survivor));11        GC.Collect();12        gens.Add(GC.GetGeneration(survivor));13 14        var big = new byte[100_000];15        GC.KeepAlive(survivor);16        return $"small array generation after 0,1,2,3 collections: {string.Join(",", gens)} | " +17               $"100 KB array starts in generation {GC.GetGeneration(big)} (MaxGeneration={GC.MaxGeneration})";18    }19}

The small array was promoted one generation per collection until it reached the top, gen 2; the 100 KB array reported gen 2 from the start. (GC.Collect() here is for the demonstration only; production code almost never needs it.)

What the GC does not know about is anything outside managed memory: file handles, sockets, database connections, locks. It also does not run at a predictable moment. A FileStream you stopped using may keep the file locked until some unknown future collection. That is what IDisposable is for: a Dispose() method that releases the resource now, called by your code.

using guarantees Dispose

using (var file = File.OpenRead(path))
{
    // read
}

// compiles to the equivalent of:
var file = File.OpenRead(path);
try { /* read */ }
finally { file?.Dispose(); }

The C# 8 using declaration, using var file = ...;, does the same, with Dispose running when the enclosing scope ends. Several in one scope are disposed in reverse order of declaration, and the finally means it happens even when an exception leaves the scope:

1public sealed class Tracked : IDisposable2{3    private readonly string _name;4    private readonly List<string> _log;5 6    public Tracked(string name, List<string> log)7    {8        _name = name;9        _log = log;10        log.Add("open " + name);11    }12 13    public void Dispose() => _log.Add("dispose " + _name);14}15 16public static class Solution17{18    static void Work(List<string> log)19    {20        using var a = new Tracked("a", log);21        using var b = new Tracked("b", log);22        log.Add("working");23        throw new InvalidOperationException("failed mid-way");24    }25 26    public static string Describe()27    {28        var log = new List<string>();29        try { Work(log); }30        catch (InvalidOperationException e) { log.Add("caught: " + e.Message); }31        return string.Join(" | ", log);32    }33}

Both resources were disposed, newest first, before the catch outside ever ran.

Finalizers

A class that directly owns an unmanaged handle can declare a finalizer (~MyType()), which the GC calls at some point after the object becomes unreachable. It is a safety net, not a cleanup plan: it runs late, on a separate thread, in no particular order, and objects with finalizers survive at least one extra collection. The standard pattern is for Dispose() to release the resource and call GC.SuppressFinalize(this); in practice, wrap raw handles in a SafeHandle and you rarely write a finalizer at all.

Common mistakes

• Relying on the GC to close a file or connection. It frees memory whenever it likes and knows nothing about the file lock.
• Calling Dispose without try/finally. An exception before that line skips it. Use using.
• A Dispose that throws on the second call. Callers may dispose twice (a using plus an explicit call); make it idempotent with a _disposed flag.
• Committing work in Dispose. Dispose also runs after an exception, so it must not assume the work succeeded. Commit explicitly, and let undo what was not committed, which is what the exercise builds.