Kako Go upravlja memorijom i skupljanjem garbage-a?

Question

Accepted Answer

Go **automatski upravlja memorijom** s garbage collectorom, oslobađajući vas od ručne dodjele/oslobađanja. Njegov GC je **konkurentan, niskozaminski, ne-generacijski mark-and-sweep** kolektor dizajniran da minimizira vremenske zaustavke — ključan razlog zašto je Go prikladan za usluge osjetljive na latenciju.

## Stack nasuprot heapu i analiza escapa

```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-ov kompajler izvršava **analizu escapa** tijekom kompajliranja: vrijednosti koje ne mogu nadživjeti svoju funkciju ostaju na jeftinom, automatski-oslobođenom **stacku**; vrijednosti čiji se referencu proslijeđuju van idu na **heap** (gdje GC upravlja njima). Alokacija na stacku je praktički besplatna, pa minimizacija heap escapeova smanjuje GC rad.

## Garbage collector: konkurentno 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 namjerno daje prioritet **niskom vremenu zaustavka** u odnosu na bruto propusnost — GC izvršava većinu rada konkurentno s vašim programom, održavajući "stop-the-world" zaustavke vrlo kratkima. To čini Go jakim za servere osjetljive na latenciju.

## Ugađanje GC-a

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

## Smanjenje GC pritiska (tehnika performansi)

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

Manje alokacija = manji GC rad. `sync.Pool` (ponovna upotreba objekata), prealokacija i minimizacija escapeova su glavni načini za smanjenje GC pritiska u vrućim dijelovima koda.

## Memory leakovi i dalje se javljaju

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

## Zašto je važno

Go-ova automatska upravljanja memorijom je velika dobit u produktivnosti i sigurnosti (nema ručnog oslobađanja, nema visilih pokazivača), ali razumijevanje *kako* funkcionira je vrijednog za aplikacije osjetljive na performanse i latenciju — za koje se Go često odabira.

Kljući uvidi: **analiza escapa** određuje alokaciju na stacku nasuprot heapu (stack je besplatan; minimizacija heap escapeova smanjuje GC rad), i Go-ov **konkurentan, niskozaminski GC** daje prioritet kratkim pauzama u odnosu na propusnost (idealno za servere, za razliku od kolektora orijentiranih na propusnost).

Znanje kako smanjiti GC pritisak (`sync.Pool`, prealokacija, manje alokacija u vrućim petljama), ga ugoditi (`GOGC`, `GOMEMLIMIT`) i prepoznati da se **leakovi i dalje javljaju** iz perzistentnih referenci (posebno goroutine leakovi) je važno za upravljanje visoko-performantnih Go usluga.

Ovo je duboko, praktično znanje koje razlikuje iskusne Go razvijatelje i česta je napredna tema razgovora za uloge osjetljive na performanse.