Hvordan fungerer hukommelsesstyring og garbage collection i .NET?

Question

Accepted Answer

.NET styrer hukommelse **automatisk** via en **garbage collector (GC)** — det allokerer objekter på den administrerede heap og frigør dem, der ikke længere er tilgængelige, så du ikke manuelt skal frigive hukommelse. Det er vigtigt at forstå GC'en (generationel, stack/heap-opdelingen og `IDisposable`) for ydeevne og korrekthed.

## Stack vs heap

```text
Stack → value types (locals), method frames; fast, automatically freed when scope ends.
Heap  → reference type objects (class instances); managed by the GC.
A reference variable lives on the stack but points to its object on the heap.
```

## Den generationelle garbage collector

```text
The GC divides the heap into GENERATIONS (based on the "most objects die young" idea):
  Gen 0 → newest objects; collected FREQUENTLY (fast, cheap)
  Gen 1 → survived one collection
  Gen 2 → long-lived objects; collected RARELY (expensive)
  (+ Large Object Heap for big objects)
→ Collecting young generations often + old ones rarely makes the GC efficient.
```

GC'en markerer tilgængelige objekter (fra rødder: stack, statiske felter) og frigør resten. Den er **generationel** — de fleste objekter dør unge, så Gen 0 indsamles ofte og billigt, mens langlivede objekter i Gen 2 indsamles sjældent.

## IDisposable og using — for uadministrerede ressourcer

```csharp
// the GC handles MANAGED memory, but NOT unmanaged resources (files, connections, handles)
// → implement IDisposable and use `using` for deterministic cleanup
using (var file = new StreamReader("data.txt"))
{
    // use file
}   // file.Dispose() called automatically — releases the file handle NOW
```

GC'en frigør administreret hukommelse, men **uadministrerede ressourcer** (filhåndtag, DB-forbindelser, sockets) kræver eksplicit oprydning via **`IDisposable`/`Dispose()`** — `using`-sætningen garanterer dette deterministisk (du venter ikke på GC'en).

## Hukommelseslækager sker stadig

```text
The GC frees only UNREACHABLE objects. "Leaks" come from lingering references:
  ✗ static collections/caches that only grow
  ✗ un-unsubscribed event handlers (the publisher keeps subscribers alive!)
  ✗ long-lived objects holding references to short-lived ones
```

## Hvorfor det betyder noget

At forstå .NET-hukommelsesstyring og garbage collection er værdifuld viden på seniorniveau for at skrive præstationsdygtig, korrekt C# — selvom GC'en fritager dig fra manuel hukommelsesstyring (en stor produktivitets- og sikkerhedsfordel, der eliminerer manuel `free` og baumende pointere), betyder det noget at forstå *hvordan* det fungerer for ydelsesfølsomme applikationer og undgå subtile fejl.

At kende den **generationelle GC** (Gen 0 indsamles hyppigt og billigt, Gen 2 sjældent men dyrt, baseret på observationen af, at de fleste objekter dør unge) hjælper dig med at resonnere om allokeringsmønstre og GC-pres (at reducere allokeringer, især af kortlivede objekter, sænker GC-omkostningerne).

Forskellen mellem **stack og heap** (værditypedata på stacken, referenceobj ekter på heapen) forbinder til værdi-/referencetypen-modellen.

Kritisk vigtig er det at forstå **`IDisposable`/`Dispose()` og `using`-sætningen** — det er essentielt og praktisk: GC'en styrer *hukommelse*, men ikke *uadministrerede ressourcer* (filhåndtag, databaseforbindelser, sockets), som kræver deterministisk oprydning via `using` — at undlade at disponere disse medfører ressourcelækager (en klassisk .NET-fejl).

Ligeledes vigtig er det at genkende, at **hukommelseslækager stadig opstår** på trods af GC'en, fra vedvarende referencer (voksende statiske cacheminds, unabonemerede event handlers, der holder subscribers i live — en klassisk C#-lækage).

At forstå GC'ens generationelle model, ressource-dispositionsmønsteret (`IDisposable`/`using`) og årsagerne til lækager er vigtigt for at skrive præstationsdygtig, lækagefri C#, især i langkørende applikationer — hvilket gør det til værdifuld viden, der adskiller udviklere, der kan bygge effektive, korrekte .NET-applikationer, og det er et almindeligt spørgsmål på seniorniveau-interviews.