Dispose and garbage collection

See it

In the lending API

The same repository before and after the fix. It is slice 3 code (the database), shown early because this is the classic leak. Press Next line to walk through it.

What they ask next

Interviewers check that you can explain every line. Tap a question to open it.

• Explain this lineWhen exactly does using var dispose?

  At the end of the block it is declared in, here the method's closing brace. Several using var lines are disposed in reverse order. The compiler writes it as try { … } finally { conn?.Dispose(); }, so it runs even when an exception is thrown.

  • What about the older using (…) { } form?

    Same thing, but you choose the block with braces. Use it when the object should be disposed before the method ends, for example to give a connection back before a slow calculation.

• Why not…Why not call conn.Close() at the end?

  If any line before it throws, Close() never runs and the connection leaks. using is a try/finally, so it always runs. For SqlConnection, Dispose calls Close, and both give the connection back to the pool.

• Explain this lineWhy await using and not plain using?

  In async code, use await using on types that implement IAsyncDisposable, the async version with DisposeAsync(), so cleanup that talks to the network or disk does not block a thread. For SqlConnection the gain is small. For a stream that still has to flush data to a file or a socket, it matters.

• Doesn't the garbage collector clean this up?

  It frees memory when it decides to, usually after enough new objects are made, not when connections run out. It never calls Dispose(). In the test, a forced GC.Collect() let the pool take the leaked connections back, because the pool notices their owner object is gone. In production you cannot wait for that, and calling GC.Collect() yourself is a code smell.

  • What is a finalizer?

    A ~ClassName() method the GC runs before it frees an object. It runs late, on a separate thread, in no fixed order, and it makes collection slower. Only a class that directly owns an operating-system handle needs one, and SafeHandle, a built-in wrapper that closes an OS handle, usually does that job for you.

• What is the Dispose pattern, Dispose(bool)?

  For classes that own an operating-system handle directly, or that others will inherit from. Public Dispose() calls Dispose(true) and GC.SuppressFinalize(this); the finalizer calls Dispose(false). If your class only holds other disposables, like a connection, make it sealed and write a plain Dispose() that disposes them.

• What if Dispose is called twice?

  It must be safe. Keep a disposed flag and return early the second time. Other methods called after Dispose should throw ObjectDisposedException.

• Who disposes the objects the DI container builds?

  The container does. Scoped and transient objects that implement IDisposable are disposed when their scope ends, which in ASP.NET Core is the end of the request. Singletons are disposed when the app shuts down. Never dispose an object that was injected into you: you don't own it. Objects you build yourself and register with AddSingleton(instance) are not disposed by the container.

  • How can that cause a leak?

    A transient disposable taken from the root provider, the app-wide scope, is kept until the app stops, so every one ever created stays in memory. More on the scope page.

• How does EF Core handle connections?

  A DbContext opens a connection for each query or save and closes it right after, unless a transaction is open; the request scope disposes the DbContext. Leaks like this one come from ADO.NET (the low-level SqlConnection/SqlCommand API, as here) or Dapper (a thin library on top).

• How would you spot pool exhaustion in production?

  Errors that say max pool size was reached; the app slow under load while SQL Server's CPU is low; the session count for the app stuck at the pool limit in sys.dm_exec_sessions. The SqlClient counter number-of-reclaimed-connections, read with dotnet-counters, counts connections the GC had to reclaim because nobody disposed them. Above 0 means a leak.

  • Why not just raise Max Pool Size?

    The leak fills a bigger pool too, only a little later, and each extra connection costs memory on SQL Server. Find the code path that doesn't dispose.

• Should I dispose an HttpClient after each call?

  No. That is the classic exception: a new HttpClient per call can run out of sockets under load. One shared instance has the opposite problem: it never sees DNS changes. Use IHttpClientFactory, or one shared instance with PooledConnectionLifetime set. Disposable does not always mean dispose after each use.

• Does Dispose free the object's memory?

  No. It releases the outside thing, like the connection. The object stays in memory until no reference reaches it and the GC collects it.

Traps

• Don't sayThe garbage collector calls Dispose for me.SayThe GC never calls Dispose(). A finalizer, if the class has one, runs late and only cleans up operating-system handles.
• Don't sayDispose frees the object's memory.SayDispose releases the connection or file now. The GC frees the memory later.
• Don't sayPool timeouts? Raise Max Pool Size.SayFind the connection that is never disposed. A bigger pool only delays the timeout.