Hvordan administrerer Go hukommelse og garbage collection?

Question

Accepted Answer

Go **administrerer hukommelse automatisk** med en garbage collector, hvilket frigør dig fra manuel allokering/frigivelse. Dens GC er en **concurrent, low-latency, non-generational mark-and-sweep** collector designet til at minimere pausetider — en vigtig grund til, at Go er egnet til latency-følsomme tjenester.

## Stack vs heap og 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
}
```

Gos compiler udfører **escape analysis** på kompileringstidspunktet: værdier, der ikke overlever deres funktion, forbliver på den billige, automatisk-frigivet **stack**; værdier, hvis referencer escaper, går på **heap** (hvor GC administrerer dem). Stack-allokering er essensen gratis, så minimering af heap escapes reducerer GC-arbejde.

## Garbage collector: concurrent 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 prioriterer bevidst **lave pausetider** over rå throughput — GC'en udfører det meste af arbejdet concurrent med dit program, hvilket holder "stop-the-world" pauser meget korte. Dette gør Go stærk til latency-følsomme servere.

## Tuning af GC'en

```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
```

## Reducering af GC-tryk (performance-teknik)

```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
```

Førre allokeringer = mindre GC-arbejde. `sync.Pool` (objektgenbruk), præallokering og minimering af escapes er de vigtigste måder at reducere GC-tryk i hot paths.

## Hukommelsesudsivninger forekommer stadig

```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
```

## Hvorfor det betyder noget

Gos automatiske hukommelsesadministration er en stor produktivitets- og sikkerhedsgevinst (ingen manuel free, ingen baumende pointere), men forståelse af *hvordan* det fungerer, er værdifuld for performance-kritiske og latency-følsomme applikationer — som Go ofte vælges til.

Vigtige indsigter: **escape analysis** bestemmer stack vs heap-allokering (stack er gratis; minimering af heap escapes reducerer GC-arbejde), og Gos **concurrent, low-latency GC** prioriterer korte pauser over throughput (idealt til servere, ulig throughput-fokuserede collectorer).

At vide, hvordan man reducerer GC-tryk (`sync.Pool`, præallokering, færre allokeringer i hot loops), tuner det (`GOGC`, `GOMEMLIMIT`), og erkender, at **udsivninger stadig forekommer** fra vedvarende referencer (især goroutine-udsivninger), er vigtigt for at drive høj-performance Go-tjenester.

Dette er dyb, praktisk viden, der adskiller senior Go-udviklere og er et almindeligt avanceret interviewemne til performance-følsomme roller.