Come Go gestisce la memoria e la raccolta dei rifiuti?

Question

Accepted Answer

Go **gestisce automaticamente la memoria** con un garbage collector, liberandoti dall'allocazione/deallocazione manuale. Il suo GC è un collector **concorrente, a bassa latenza, mark-and-sweep non generazionale** progettato per minimizzare i tempi di pausa — una ragione chiave per cui Go è adatto ai servizi sensibili alla latenza.

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

Il compilatore di Go esegue **escape analysis** in fase di compilazione: i valori che non sopravvivono alla loro funzione rimangono nello **stack** economico e automaticamente liberato; i valori i cui riferimenti sfuggono vanno sull'**heap** (dove il GC li gestisce). L'allocazione dello stack è essenzialmente gratuita, quindi minimizzare le escape su heap riduce il lavoro del GC.

## Il garbage collector: mark-and-sweep concorrente

```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 deliberatamente privilegia i **tempi di pausa bassi** rispetto al puro throughput — il GC fa la maggior parte del lavoro contemporaneamente al tuo programma, mantenendo le pause "stop-the-world" molto brevi. Questo rende Go forte per i server sensibili alla latenza.

## Sintonizzazione del 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
```

## Ridurre la pressione sul GC (tecnica di performance)

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

Meno allocazioni = meno lavoro del GC. `sync.Pool` (riutilizzo di oggetti), preallocazione e minimizzazione delle escape sono i principali modi per ridurre la pressione sul GC nei percorsi critici.

## Le memory leak accadono ancora

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

## Perché è importante

La gestione automatica della memoria di Go è una vittoria principale per la produttività e la sicurezza (niente free manuale, niente puntatori pendenti), ma comprendere *come* funziona è prezioso per le applicazioni critiche per le performance e sensibili alla latenza — per le quali Go è spesso scelto.

Approfondimenti chiave: **escape analysis** determina l'allocazione stack vs heap (lo stack è gratuito; minimizzare le escape su heap riduce il lavoro del GC), e il **GC concorrente a bassa latenza** di Go privilegia le pause brevi rispetto al throughput (ideale per i server, a differenza dei collector orientati al throughput).

Sapere come ridurre la pressione sul GC (`sync.Pool`, preallocazione, meno allocazioni nei loop critici), sintonizzarlo (`GOGC`, `GOMEMLIMIT`), e riconoscere che **le leak accadono ancora** da riferimenti persistenti (specialmente goroutine leak) è importante per gestire servizi Go ad alte performance.

Questa è conoscenza profonda e pratica che distingue gli sviluppatori Go senior e è un argomento di intervista avanzato comune per i ruoli sensibili alle performance.