Does C# have destructors? Explain finalisers, how the garbage collector runs them, why they are non-deterministic and costly, and how they relate to IDisposable, the dispose pattern and SafeHandle.

1. Finalisation queues in the runtime

• Finalisation queue (registration list): every finalisable object is added at allocation. GC.SuppressFinalize clears a header bit so the GC ignores it.
• F-reachable queue: objects found dead but needing finalisation. This queue is a GC root.
• Finaliser thread: a high-priority thread running Finalize() methods one at a time.

GC.ReRegisterForFinalize(obj) re-adds an object (used in resurrection scenarios). GC.WaitForPendingFinalizers() blocks until the f-reachable queue drains — handy in tests, dangerous in production.

2. Cost model

Allocating many finalisable objects (e.g. thousands of wrappers per second) noticeably increases GC cost.

3. Critical finalisers and SafeHandle internals

SafeHandle derives from CriticalFinalizerObject, whose finalisers run after normal finalisers and are prepared ahead of time so they can run even in low-resource situations. Internally it tracks state (closed, disposed) and a reference count:

• P/Invoke marshalling calls DangerousAddRef before the native call and DangerousRelease after, so a concurrent Dispose can't free the handle mid-call.
• ReleaseHandle() is called exactly once when the count hits zero and the handle is closed.

This fixes the classic IntPtr handle-recycling race, where a closed handle number is reused by the OS for another resource and the stale IntPtr operates on the wrong object.

4. Finalisers and process exit

.NET Framework ran finalisers on shutdown (with a timeout). .NET Core/.NET 5+ does not: on process exit, pending finalisers are not guaranteed to run. Never rely on finalisers for flushing files, sending telemetry, or releasing external locks — use IHostApplicationLifetime.ApplicationStopping, IAsyncDisposable on DI services, or AppDomain.ProcessExit for best-effort work.

5. DI and disposal

The ASP.NET Core DI container disposes services it created when their scope ends (scoped services at the end of the request, singletons at shutdown), calling DisposeAsync if available. Services you register as instances (AddSingleton(myObj)) are not disposed by the container. Transient disposables resolved from the root provider are tracked until the app stops — a known memory-leak trap.

6. Diagnosing finaliser problems

• dotnet-counters: watch gc-heap-size, gen-2-gc-count; .NET exposes finalisation-related events via EventPipe.
• dotnet-dump analyze → finalizequeue shows registered and f-reachable objects by type; threads/clrstack on the finaliser thread shows if it's blocked.
• Analysers: CA1063 (implement IDisposable correctly), CA1816 (call SuppressFinalize), CA2000 (dispose objects before losing scope), CA2213 (disposable fields should be disposed).

Try it yourself

1. Allocate 100,000 objects with and without a finaliser and compare GC counts and promotion with BenchmarkDotNet's [MemoryDiagnoser].
2. Write a finaliser that sleeps for a second and watch the finalisation queue grow in dotnet-dump.
3. Implement a custom SafeHandle for a native allocation and verify it's released without a finaliser in your class.
4. Show that a finaliser doesn't run on process exit in .NET 10.

using Microsoft.Win32.SafeHandles;
using System.Runtime.InteropServices;

// 1. Most classes: managed disposables only, sealed, no finaliser
public sealed class ReportWriter(Stream output) : IDisposable
{
    private readonly StreamWriter _writer = new(output);
    private bool _disposed;

    public void Write(string line)
    {
        ObjectDisposedException.ThrowIf(_disposed, this);
        _writer.WriteLine(line);
    }

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

// 2. Unmanaged handle: let SafeHandle own the finaliser
internal sealed class NativeBufferHandle : SafeHandleZeroOrMinusOneIsInvalid
{
    public NativeBufferHandle() : base(ownsHandle: true) { }
    protected override bool ReleaseHandle() => NativeMethods.FreeBuffer(handle);
}

// 3. Unsealed base class: the dispose pattern
public class ImageProcessor : IDisposable
{
    private readonly NativeBufferHandle _buffer = NativeMethods.AllocBuffer(1 << 20);
    private bool _disposed;

    public void Dispose()
    {
        Dispose(disposing: true);
        GC.SuppressFinalize(this);       // harmless here, needed if a subclass adds a finaliser
    }

    protected virtual void Dispose(bool disposing)
    {
        if (_disposed) return;
        if (disposing)
            _buffer.Dispose();           // managed objects only when disposing
        _disposed = true;
    }
}

internal static partial class NativeMethods
{
    [LibraryImport("imaging")]
    internal static partial NativeBufferHandle AllocBuffer(int size);

    [LibraryImport("imaging")]
    [return: MarshalAs(UnmanagedType.Bool)]
    internal static partial bool FreeBuffer(nint buffer);
}

// Usage: deterministic clean-up
using var processor = new ImageProcessor();