Hoe beheer Go het geheugen en garbage collection?

Question

Accepted Answer

Go **beheert het geheugen automatisch** met een garbage collector, waardoor je niet handmatig geheugen hoeft toe te wijzen en vrij te geven. De GC is een **gelijktijdige, lage-latentie, niet-generationele mark-and-sweep** collector die is ontworpen om pauzestijden te minimaliseren — een sleutelreden waarom Go geschikt is voor latentie-gevoelige services.

## Stack versus heap en escape analysis

```go
// the compiler decides where each value lives via ESCAPE ANALYSIS
func noEscape() int {
    x := 42        // stays on the STACK — doesn't escape, freed when function returns (cheap)
    return x
}
func escapes() *int {
    x := 42        // ESCAPES to the HEAP — its pointer outlives the function (GC-managed)
    return &x
}
```

Go's compiler voert **escape analysis** uit op compileertijd: waarden die niet langer leven dan hun functie, blijven op de goedkope, automatisch-vrijgegeven **stack**; waarden waarvan de verwijzingen ontsnappen, gaan naar de **heap** (waar de GC ze beheert). Stack-toewijzing is essentieel gratis, dus het minimaliseren van heap-escapes vermindert GC-werk.

## De garbage collector: gelijktijdige mark-and-sweep

```text
Go's GC characteristics:
  ✓ MARK-AND-SWEEP — marks reachable objects (from roots), sweeps the rest
  ✓ CONCURRENT — runs mostly alongside your program (not stop-the-world)
  ✓ LOW LATENCY — optimized for short pauses (typically sub-millisecond), not throughput
  ✓ NON-GENERATIONAL — unlike the JVM, treats all objects uniformly (simpler)
```

Go geeft bewust de voorkeur aan **lage pauzestijden** boven ruwe doorvoer — de GC voert het meeste werk gelijktijdig met je programma uit, waarbij "stop-the-world"-pauzes zeer kort worden gehouden. Dit maakt Go sterk voor latentie-gevoelige servers.

## Tunen van de GC

```bash
GOGC=100   # default: trigger GC when heap grows 100% since the last collection
           # higher GOGC → less frequent GC (more memory, less CPU)
           # lower GOGC → more frequent GC (less memory, more CPU)
GOMEMLIMIT=2GiB   # a soft memory limit (Go 1.19+) — GC works harder near it
```

## GC-druk verminderen (prestatietechniek)

```go
// 1. reuse objects with sync.Pool to reduce allocations
var bufPool = sync.Pool{New: func() any { return new(bytes.Buffer) }}
buf := bufPool.Get().(*bytes.Buffer)
defer bufPool.Put(buf)

// 2. preallocate slices with known capacity (avoid repeated growth/realloc)
data := make([]int, 0, 1000)

// 3. minimize heap escapes; avoid unnecessary pointers/allocations in hot loops
```

Minder toewijzingen = minder GC-werk. `sync.Pool` (objecthergebruik), pre-toewijzing en het minimaliseren van escapes zijn de voornaamste manieren om GC-druk in hot paths te verminderen.

## Geheugenlekkages gebeuren nog steeds

```text
GC frees only UNREACHABLE objects. Leaks come from lingering REFERENCES:
  ✗ goroutine leaks (a blocked goroutine keeps its referenced memory alive)
  ✗ growing global maps/slices, unclosed resources, forgotten subscriptions
```

## Waarom het belangrijk is

Go's automatische geheugenbeheering is een grote productiviteits- en veiligheidswins (geen handmatig freeen, geen bungelnde pointers), maar het begrijpen van *hoe* dit werkt, is waardevol voor prestatiekritieke en latentie-gevoelige applicaties — waarvoor Go vaak wordt gekozen.

Kernpunten: **escape analysis** bepaalt stack versus heap-toewijzing (stack is gratis; het minimaliseren van heap-escapes vermindert GC-werk), en Go's **gelijktijdige, lage-latentie GC** geeft prioriteit aan korte pauzes boven doorvoer (ideaal voor servers, in tegenstelling tot doorvoer-gerichte collectors).

Weten hoe je GC-druk kunt verminderen (`sync.Pool`, pre-toewijzing, minder toewijzingen in hot loops), deze kunt tunen (`GOGC`, `GOMEMLIMIT`), en erkennen dat **lekkages nog steeds voorkomen** van blijvende verwijzingen (vooral goroutine-lekkages) is belangrijk voor het beheren van krachtige Go-services.

Dit is diep, praktisch kennis dat seniore Go-ontwikkelaars onderscheidt en is een veelvoorkomend geavanceerd interviewonderwerp voor prestatiegevoelige rollen.