Como o Go gerencia memória e coleta de lixo?

Question

Accepted Answer

Go **gerencia automaticamente memória** com um coletor de lixo, liberando você da alocação/liberação manual. Seu GC é um coletor **concorrente, de baixa latência, não-geracional mark-and-sweep** projetado para minimizar tempos de pausa — uma razão-chave pela qual o Go é adequado para serviços sensíveis à latência.

## Stack vs heap e análise de escape

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

O compilador do Go executa **análise de escape** em tempo de compilação: valores que não sobrevivem além de sua função permanecem na **stack** barata e automaticamente liberada; valores cujas referências escapam vão para a **heap** (onde o GC os gerencia). A alocação de stack é essencialmente gratuita, então minimizar escapes de heap reduz o trabalho do GC.

## O coletor de lixo: 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)
```

O Go deliberadamente prioriza **tempos de pausa baixos** sobre vazão bruta — o GC faz a maior parte do trabalho concorrentemente com seu programa, mantendo pausas "stop-the-world" muito curtas. Isso torna o Go forte para servidores sensíveis à latência.

## Ajustando o 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
```

## Reduzindo pressão do GC (técnica de desempenho)

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

Fewer allocations = less GC work. `sync.Pool` (reutilização de objetos), pré-alocação, e minimização de escapes são os principais modos de reduzir pressão do GC em caminhos críticos.

## Vazamentos de memória ainda acontecem

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

## Por que isso importa

O gerenciamento automático de memória do Go é uma grande vitória em produtividade e segurança (sem free manual, sem ponteiros pendentes), mas entender *como* funciona é valioso para aplicações críticas de desempenho e sensíveis à latência — pelas quais o Go é frequentemente escolhido.

Insights-chave: **análise de escape** determina alocação de stack vs heap (stack é gratuita; minimizar escapes de heap reduz o trabalho do GC), e o **GC concorrente, de baixa latência** do Go prioriza pausas curtas sobre vazão (ideal para servidores, diferentemente de coletores focados em vazão).

Saber como reduzir pressão do GC (`sync.Pool`, pré-alocação, menos alocações em loops críticos), ajustá-lo (`GOGC`, `GOMEMLIMIT`), e reconhecer que **vazamentos ainda ocorrem** de referências persistentes (especialmente vazamentos de goroutine) é importante para operar serviços Go de alto desempenho.

Este é conhecimento profundo e prático que distingue desenvolvedores Go sênior e é um tópico avançado comum em entrevistas para funções sensíveis ao desempenho.