Zarządzanie pamięcią w .NET: jak działa Garbage Collector i jak pisać kod, który go nie męczy

W .NET pamięcią zarządza za Ciebie Garbage Collector (GC). Cyklicznie odnajduje obiekty, których już nie używasz, i zwalnia zajmowaną przez nie pamięć. Brzmi jak wygoda, o której nie trzeba myśleć, i przez większość czasu faktycznie tak jest.

Problem pojawia się dopiero wtedy, gdy aplikacja musi działać naprawdę szybko: przy dużym ruchu, w gorących ścieżkach kodu czy w usługach serwerowych. Nieświadome tworzenie tysięcy krótkotrwałych obiektów potrafi zamienić się w częste pauzy na sprzątanie, skoki zużycia CPU i nieprzewidywalne opóźnienia. A to już bezpośrednio uderza w wydajność i skalowalność.

W tym artykule wyjaśniam, jak działa GC w .NET - tryby pracy, generacje i Large Object Heap, a następnie pokazuję konkretne, poparte kodem techniki, dzięki którym ograniczysz liczbę alokacji i odciążysz kolektor. To wiedza przydatna zarówno dla programisty piszącego gorący fragment kodu, jak i dla lidera technicznego, który chce rozumieć, jak decyzje projektowe przekładają się na zużycie zasobów.

Jak działa GC w .NET

Large Object Heap (LOH)

Tryby pracy GC: Workstation vs Server

<PropertyGroup>
  <ServerGarbageCollection>true</ServerGarbageCollection>
  <ConcurrentGarbageCollection>true</ConcurrentGarbageCollection>
</PropertyGroup>

Co uruchamia GC?

Kolektor sam decyduje, kiedy posprzątać stertę. Najczęstsze wyzwalacze to: mało dostępnej pamięci RAM, przekroczenie wewnętrznego progu rozmiaru sterty dla danej generacji oraz jawne wywołanie GC.Collect() (odradzane w zwykłym kodzie, kolektor niemal zawsze wie lepiej).

Zależność jest prosta: im więcej i im szybciej alokujesz, tym więcej pracy ma GC. Wysokie tempo alokacji (tzw. duża presja na GC) oznacza częstsze pauzy, większe zużycie CPU, a przez fragmentację nierzadko także wyższe zużycie pamięci. Dlatego najskuteczniejsza optymalizacja to zwyczajnie alokować mniej.

Zanim zaczniesz optymalizować: zmierz

Praktyczne techniki ograniczania alokacji

/* Alokuje nowy string przy każdym wywołaniu */
string domena = email.Substring(email.IndexOf('@') + 1);

/* Zero alokacji - tylko widok na istniejący string */
ReadOnlySpan<char> domena = email.AsSpan(email.IndexOf('@') + 1);

Dla małych, tymczasowych buforów świetnie sprawdza się też stackalloc, który alokuje pamięć na stosie, całkowicie omijając GC:

Span<byte> bufor = stackalloc byte[256]; /* na stosie, poza zasięgiem GC */
/* ... praca na buforze bez ani jednej alokacji na stercie */

W gorących sekcjach kodu Span/Memory zamiast kopiowania danych to zwykle czysty zysk wydajnościowy.

2. Reużywaj obiekty - pule i buforowanie

Tworzenie i porzucanie wielu obiektów tego samego typu to prosta droga do wysokiej presji na GC. Zamiast tego - wypożyczaj i zwracaj.

.NET udostępnia gotową pulę tablic przez ArrayPool<T>. Zamiast alokować nową tablicę na każde żądanie, wypożyczasz ją z puli i zwracasz po użyciu:

byte[] bufor = ArrayPool<byte>.Shared.Rent(1024);
try
{
    /* Uwaga: wypożyczona tablica może być WIĘKSZA niż 1024 */
    /* korzystaj tylko z tylu bajtów, ile faktycznie potrzebujesz. */
    int odczytano = strumien.Read(bufor, 0, 1024);
    /* ... */
}
finally
{
    ArrayPool<byte>.Shared.Return(bufor);
}

W aplikacjach o dużym ruchu sieciowym lub intensywnym I/O potrafi to drastycznie obniżyć częstotliwość odśmiecania. W typowych scenariuszach przejście z alokacji "na żądanie" na pulowanie potrafi zredukować liczbę kolekcji GC o kilkadziesiąt procent i wygładzić skoki opóźnień.

Analogicznie działa Microsoft.Extensions.ObjectPool dla kosztownych w utworzeniu obiektów (parsery, bufory, StringBuilder). Jeden warunek: zawsze resetuj stan obiektu przed zwróceniem do puli, żeby nie przenosić "brudnych" danych między użyciami. Reużywanie dużych struktur ma bonus - ogranicza fragmentację LOH, bo przestajesz nieustannie przydzielać i zwalniać wielkie segmenty.

3. Używaj struct dla małych, często używanych danych

Typy wartościowe (struct) zwykle żyją na stosie albo wewnątrz innych obiektów, a nie na zarządzanej stercie, więc nie obciążają bezpośrednio GC. Dla drobnych, niezmiennych danych to potrafi wyeliminować mnóstwo krótkotrwałych alokacji:

/* Klasa: każdy punkt to osobny obiekt na stercie */
public class PunktClass { public double X; public double Y; }

/* Struktura: żyje na stosie lub w tablicy - bez presji na GC */
public readonly struct Punkt
{
    public Punkt(double x, double y) => (X, Y) = (x, y);
    public double X { get; }
    public double Y { get; }
}

Tablica miliona Punkt to jeden ciągły blok pamięci, zero miliona osobnych obiektów do posprzątania. Ale uważaj na 2 pułapki:
• Duże struktury (kilkadziesiąt bajtów i więcej) są kosztowne w kopiowaniu, wtedy przewaga znika.
• Boxing (rzutowanie struktury na object lub interfejs) tworzy obiekt na stercie i niweczy cały zysk.

4. Uważaj na ukryte alokacje w "wygodnym" kodzie

Najczęstsze śmieci to te, których nie widać wprost. Wygodny, czytelny kod potrafi pod spodem generować sporo obiektów tymczasowych.

LINQ alokuje delegaty, iteratory i kolekcje, a każde ToList() tworzy nową listę:

/* Alokuje delegat, iterator i nową listę */
var wynik = kolekcja.Where(x => x.Aktywny).Select(x => x.Id).ToList();

/* W gorącej ścieżce: prosta pętla, zero pośrednich alokacji */
var wynik = new List<int>();
foreach (var x in kolekcja)
    if (x.Aktywny)
        wynik.Add(x.Id);

Konkatenacja stringów w pętli tworzy nowy string przy każdej iteracji (stringi są niezmienne):

/* Każda iteracja alokuje nowy string */
string s = "";
foreach (var cz in czesci) s += cz;

/* Jeden bufor, rośnie w miarę potrzeb */
var sb = new StringBuilder();
foreach (var cz in czesci) sb.Append(cz);
string s = sb.ToString();

Dochodzą do tego domknięcia (closures) - lambda przechwytująca zmienną z zewnątrz również tworzy dodatkowy obiekt na stercie.

Zasada dla gorących ścieżek: preferuj proste pętle for/foreach zamiast kaskad LINQ, StringBuilder zamiast +, i sięgaj po Span<T> oraz pulowanie tam, gdzie to możliwe. Nie chodzi o to, by wygnać LINQ z całego projektu - chodzi o to, by nie było go w kodzie wykonywanym miliony razy na sekundę.

Podsumowanie

Chcesz więcej?