C# Dispose - Jak poprawnie zwalniać zasoby i unikać błędów?

Mechanizm c# dispose dotyczy przede wszystkim bezpiecznego oddawania zasobów, których nie pilnuje sam garbage collector. W praktyce chodzi o to, kiedy wywołać Dispose, jak napisać własny typ zgodny z tym wzorcem i jak korzystać z niego w kodzie webowym, żeby nie trzymać plików, socketów ani połączeń do bazy dłużej niż trzeba.

Co właściwie robi Dispose i czego nie robi

Najkrócej: Dispose zamyka to, czego nie rozumie garbage collector. CLR odzyskuje pamięć zarządzaną, ale nie wie, kiedy zwolnić uchwyt do pliku, gniazdo sieciowe, połączenie z bazą czy deskryptor systemowy. Dlatego Dispose ma sens tam, gdzie obiekt trzyma coś poza samą pamięcią sterty.

W praktyce traktuję tę metodę jako jawny moment zakończenia odpowiedzialności. Od tej chwili obiekt nie powinien być dalej używany, a jeśli ma finalizer, to zwykle można mu już nie pozwalać na dalsze działanie przez GC.SuppressFinalize.

Ważne rozróżnienie: Dispose może sprzątać także zależności zarządzane, ale sam nie zwalnia pamięci obiektu. To nadal robi garbage collector, tylko później, gdy obiekt przestanie być osiągalny. Kiedy już to rozdzielisz w głowie, łatwiej uniknąć złudzenia, że Dispose jest jakimś magicznym zamiennikiem GC.

Skoro różnica jest jasna, następnym krokiem jest decyzja, kiedy metodę wywołać ręcznie, a kiedy nie dotykać jej wcale.

Kiedy trzeba go wywołać, a kiedy nie

Ja zwykle zadaję sobie proste pytanie: kto jest właścicielem zasobu? Jeśli obiekt go otworzył, kupił albo stworzył, to najpewniej powinien go też zamknąć. Jeśli tylko go dostał „na chwilę”, nie powinien udawać właściciela.

Jeśli obiekt przekazujesz dalej, dokumentuj, kto ma go zamknąć. Niejasna własność to najkrótsza droga do wycieków albo podwójnego sprzątania. Właśnie dlatego w kolejnym kroku warto zobaczyć, jak wygląda poprawna implementacja wzorca.

Jak wygląda poprawna implementacja wzorca

W prostych klasach, które opakowują kilka zarządzanych zasobów, wystarcza zwykle zwykły publiczny Dispose i pilnowanie, by wywołać Dispose na polach. W klasach dziedziczonych albo takich, które naprawdę trzymają zasoby niezarządzane, wzorzec robi się bardziej formalny: Dispose(bool), opcjonalny finalizer i bardzo ostrożne rozdzielenie sprzątania managed oraz unmanaged state.

public sealed class ReportReader : IDisposable
{
    private readonly StreamReader _reader;
    private bool _disposed;

    public ReportReader(string path)
    {
        _reader = new StreamReader(path);
    }

    public string ReadFirstLine()
    {
        if (_disposed)
            throw new ObjectDisposedException(nameof(ReportReader));

        return _reader.ReadLine() ?? string.Empty;
    }

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

        _reader.Dispose();
        _disposed = true;
    }
}

To wystarczy, jeśli klasa jest sealed i nie zarządza niczym poza własnymi zależnościami typu IDisposable. Ja właśnie taki wariant uznaję za domyślny, bo jest najczytelniejszy i najmniej podatny na błędy.

W praktyce nie lubię ręcznie pisać finalizera, jeśli da się tego uniknąć. Oficjalny kierunek w .NET jest jasny: o ile to możliwe, lepiej zamknąć uchwyt przez SafeHandle, niż budować własny kod finalizacyjny. To mniej efektowne, ale zwykle dużo bezpieczniejsze.

public class NativeBuffer : IDisposable
{
    private IntPtr _buffer;
    private bool _disposed;

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    ~NativeBuffer() => Dispose(false);

    protected virtual void Dispose(bool disposing)
    {
        if (_disposed)
            return;

        if (disposing)
        {
            // tutaj zwalniam zależności zarządzane
        }

        if (_buffer != IntPtr.Zero)
        {
            Marshal.FreeHGlobal(_buffer);
            _buffer = IntPtr.Zero;
        }

        _disposed = true;
    }
}

To nadal jest wersja uproszczona, ale dobrze pokazuje zasadę: część zarządzana i niezarządzana muszą mieć różne ścieżki sprzątania. Jeśli nie masz realnego powodu, żeby trzymać IntPtr, nie komplikuję tego bardziej i wybieram SafeHandle.

Kiedy konstrukcja klasy jest już jasna, naturalnie pojawia się pytanie, jak korzystać z niej po stronie kodu wywołującego.

Jak używać using, using var i await using

Po stronie konsumenta najbardziej praktyczne jest krótkie, czytelne ograniczenie zakresu. using zamyka obiekt automatycznie na końcu bloku, a using var robi to samo na końcu bieżącego zakresu. W kodzie, który sam piszę, to jest pierwszy wybór, dopóki zasób nie musi żyć dłużej.

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

var reader = new StreamReader(path);
try
{
    return reader.ReadToEnd();
}
finally
{
    reader.Dispose();
}

Jeśli typ udostępnia DisposeAsync, wolę await using. To szczególnie sensowne tam, gdzie sprzątanie może obejmować operacje I/O albo współpracę z warstwą danych. Sama zasada pozostaje ta sama: zakres życia obiektu powinien być krótki i czytelny.

Gdy ten mechanizm jest już opanowany, najwięcej problemów zostaje zwykle nie w samym API, tylko w codziennych błędach użycia.

Najczęstsze błędy, które psują sprzątanie zasobów

W code review najczęściej widzę te same potknięcia. Nie są efektowne, ale właśnie dlatego wracają po cichu i wychodzą dopiero pod obciążeniem albo przy awarii.

• Zakładanie, że garbage collector zwolni uchwyt „wkrótce”. Przy plikach i socketach to za słaba strategia.
• Wywoływanie Dispose na obiekcie, którego nie stworzyłeś i nie kontrolujesz. To często kończy się błędami trudnymi do odtworzenia.
• Trzymanie obiektu po Dispose i dalsze używanie go, jakby nic się nie stało. Po zamknięciu zasobu obiekt zwykle ma być martwy.
• Pisanie własnego finalizera bez realnej potrzeby. To kosztuje więcej niż wygląda, a utrzymanie bywa kruche.
• Pomijanie GC.SuppressFinalize w klasie, która ma finalizer i już ręcznie posprzątała zasób.
• Ignorowanie asynchronicznego sprzątania wtedy, gdy typ jasno wystawia DisposeAsync.
• Tworzenie kilku zasobów w jednym zagnieżdżonym wyrażeniu bez kontroli własności, na przykład wtedy, gdy wyjątek pośrodku zostawia jeden z nich otwarty.
• Odrzucanie ostrzeżeń analizatora, zwłaszcza CA2000 i CA1063, bez sprawdzenia, czy to na pewno fałszywy alarm.

Jeśli mam wybrać jeden test jakości, to patrzę właśnie na własność: kto otwiera, kto używa i kto zamyka. Gdy odpowiedź na to pytanie jest rozmyta, kod zwykle rozmywa też odpowiedzialność. To prowadzi prosto do problemów, które w aplikacji webowej wychodzą dopiero pod ruchem.

Jak to przekłada się na aplikacje webowe i biblioteki

W aplikacjach webowych najważniejsze jest dla mnie jedno: nie mieszać własności z czasem życia żądania. Jeśli tworzę chwilowy strumień do pliku, odpowiedź z zewnętrznego API albo własny kontekst bazy poza kontenerem DI, zamykam go od razu w tym samym zakresie. Jeśli za zarządzanie odpowiada kontener, nie próbuję go dublować ręcznym Dispose w losowym miejscu kodu.

To szczególnie ważne przy pracy z bazą danych i HTTP. DbContext powinien mieć przewidywalny zakres życia, a HttpClient nie jest dobrym kandydatem do tworzenia i natychmiastowego zamykania w każdej metodzie. W tym drugim przypadku problemem bywa nie tylko sam Dispose, ale też sposób zarządzania połączeniami i handlerami. Ja wolę myśleć o tym jak o koszcie cyklu życia, a nie jak o pojedynczym wywołaniu metody.

W bibliotekach dorzucam jeszcze jedną zasadę: dokumentuję, kto ma posprzątać obiekt. To może być opis w nazwie, komentarz w API albo jasny kontrakt w kodzie. Bez tego użytkownik biblioteki zgaduje, a zgadywanie przy zasobach systemowych zwykle kończy się źle.

Na końcu zostaje reguła, która najlepiej porządkuje cały temat.

Jedna zasada, która porządkuje cały temat

Jeśli mam zostawić tylko jedną regułę, wybieram tę: każdy zasób powinien mieć jednego jasnego właściciela. Gdy właściciel jest oczywisty, Dispose przestaje być osobnym problemem i staje się zwykłą częścią projektu, tak samo naturalną jak otwarcie pliku czy wykonanie zapytania.

W praktyce sprawdza mi się prosty filtr: jeśli obiekt otwiera plik, socket, połączenie, timer albo tworzy własny IDisposable, to od razu zapisuję sobie, gdzie i kiedy zostanie zamknięty. Jeżeli nie potrafię tego wskazać w jednym zdaniu, najpierw poprawiam odpowiedzialność w kodzie, dopiero potem wracam do implementacji. To małe ograniczenie, ale bardzo skuteczne na produkcji.