Jak Go spravuje paměť a garbage collection?

Question

Accepted Answer

Go **automaticky spravuje paměť** pomocí garbage collectoru, který vás osvobozuje od ruční alokace/uvolnění. Jeho GC je **konkurenční, nízkolatenční, negenerační mark-and-sweep** collector navržený k minimalizaci pauz — klíčový důvod, proč je Go vhodný pro latencí citlivé služby.

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

Kompilér Go provádí **escape analysis** v čase kompilace: hodnoty, které nepřežijí svou funkci, zůstávají na levném, automaticky uvolňovaném **stacku**; hodnoty, jejichž reference uniknou, jdou na **heap** (kde je GC spravuje). Alokace stacku je v podstatě zdarma, takže minimalizace heap escape snižuje GC práci.

## Garbage collector: konkurenční 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 záměrně upřednostňuje **nízké doby pause** před surovou propustností — GC provádí většinu práce konkurenčně s vašim programem, čímž drží "stop-the-world" pauzy velmi krátké. To činí Go silné pro latencí citlivé servery.

## Ladění 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
```

## Snížení GC tlaku (technika výkonu)

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

Méně alokací = méně GC práce. `sync.Pool` (opakované použití objektů), preaalokace a minimalizace escape jsou hlavní způsoby, jak snížit GC tlak v kritických částech.

## Memory leaky se stále vyskytují

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

## Proč to má znaczení

Automatická správa paměti Go je velkým přínosem pro produktivitu a bezpečnost (žádné ruční uvolňování, žádné dangling pointery), ale pochopení *jak* funguje je cenné pro výkonnostně kritické a latencí citlivé aplikace — pro které je Go často voleno.

Klíčové poznatky: **escape analysis** určuje alokaci stack vs heap (stack je zdarma; minimalizace heap escape snižuje GC práci) a Go **konkurenční, nízkolatenční GC** upřednostňuje krátké pauzy před propustností (ideální pro servery, na rozdíl od GC zaměřených na propustnost).

Vědět, jak snížit GC tlak (`sync.Pool`, preaalokace, méně alokací v hot smyčkách), jak ho ladit (`GOGC`, `GOMEMLIMIT`) a uvědomit si, že **leaky se stále vyskytují** z vlivných referencí (zejména goroutine leaky) je důležité pro provoz vysoce výkonných Go služeb.

Toto je hluboké, praktické vědění, které odlišuje senior Go vývojáře a je běžné pokročilé téma v pohovorech pro role citlivé na výkon.