Garbage collector do Go: como funciona

1. Fundamentos do Garbage Collector no Go

1.1. O papel do GC em linguagens com gerenciamento automático de memória

O garbage collector (GC) é um componente essencial do runtime do Go, responsável por gerenciar automaticamente a alocação e liberação de memória no heap. Diferente de linguagens como C ou Rust, onde o programador gerencia explicitamente a memória, o Go utiliza um coletor de lixo para identificar e recuperar objetos que não são mais alcançáveis pelo programa.

Esse gerenciamento automático reduz significativamente a carga cognitiva do desenvolvedor, eliminando problemas clássicos como memory leaks por falta de free() ou double-free bugs. No entanto, o GC introduz latência e overhead computacional, exigindo um design cuidadoso em aplicações de alta performance.

1.2. Histórico: versões do GC (Go 1.0, Go 1.5, Go 1.12+)

A evolução do GC no Go reflete a busca por menor latência e maior eficiência:

• Go 1.0 (2012): Implementação inicial com coletor stop-the-world (STW) simples, causando pausas que podiam chegar a centenas de milissegundos em heaps grandes.
• Go 1.5 (2015): Marco revolucionário — introdução do GC concorrente baseado em mark-and-sweep com write barriers. Redução drástica das pausas STW para <10ms.
• Go 1.8 (2017): Otimizações nas fases de mark termination, reduzindo pausas para <1ms típico.
• Go 1.12+ (2019): Melhorias no escalonamento do GC, ajuste dinâmico de taxa e suporte a métricas mais precisas.

Atualmente, o GC do Go é um dos mais eficientes entre linguagens gerenciadas, com pausas tipicamente abaixo de 500µs.

1.3. Abordagem concorrente e não-generacional

Diferente de JVM ou .NET, que usam coletores geracionais (separando objetos jovens e velhos), o Go adota um modelo não-generacional e concorrente. Isso significa que:

• Não há gerações: Todo o heap é varrido em cada ciclo, simplificando a implementação e evitando overhead de tracking de idade.
• Concorrência: A maior parte do trabalho de marcação ocorre em paralelo com a execução das goroutines, minimizando pausas.

Essa escolha de design prioriza latência baixa e previsível sobre throughput máximo, ideal para servidores web e sistemas em tempo real.

2. Algoritmo Central: Mark-and-Sweep Concorrente

2.1. Fases do ciclo: Mark Start, Marking, Mark Termination, Sweep

O GC do Go opera em quatro fases principais:

// Exemplo simplificado do ciclo do GC
package main

import (
    "fmt"
    "runtime"
    "time"
)

func main() {
    // Simulando alocações que disparam GC
    for i := 0; i < 10; i++ {
        _ = make([]byte, 10*1024*1024) // 10MB
        runtime.GC()
        var m runtime.MemStats
        runtime.ReadMemStats(&m)
        fmt.Printf("Ciclo %d: HeapAlloc=%d KB, NumGC=%d\n", 
            i, m.HeapAlloc/1024, m.NumGC)
        time.Sleep(100 * time.Millisecond)
    }
}

Fases detalhadas:

1. Mark Start (STW breve): O GC interrompe todas as goroutines para configurar o estado inicial do ciclo (atualizar raízes, ativar write barriers). Duração típica: <10µs.
2. Marking (concorrente): Varredura do heap a partir das raízes, marcando objetos alcançáveis. Executa em paralelo com as goroutines.
3. Mark Termination (STW breve): Finalização da marcação, verificação de consistência. Duração: <100µs.
4. Sweep (concorrente): Liberação da memória de objetos não marcados. Ocorre gradualmente durante a execução normal.

2.2. Barreras de escrita (write barriers) para consistência concorrente

Write barriers são mecanismos críticos que garantem consistência quando o GC marca objetos enquanto goroutines modificam ponteiros. Sem elas, um objeto poderia ser considerado morto mesmo sendo referenciado por uma goroutine em execução.

package main

import "runtime"

type Node struct {
    value int
    next  *Node
}

// Write barrier atua automaticamente quando atribuímos ponteiros
func updatePointer(head **Node, new *Node) {
    // Internamente, o runtime insere uma write barrier
    // que notifica o GC sobre a nova referência
    *head = new
}

func main() {
    var head *Node
    node := &Node{value: 42}
    updatePointer(&head, node)
    runtime.GC()
    // node permanece alcançável via head
}

2.3. Como o GC interage com a execução das goroutines

O GC utiliza um escalonamento cooperativo: durante a fase de marking, o runtime periodicamente verifica se há trabalho de GC pendente. Se uma goroutine estiver alocando muito, ela pode ser forçada a "ajudar" o GC (GC assist), como veremos na seção 4.

3. Tricolor Marking e Rastreamento de Objetos

3.1. Conceito de objetos brancos, cinzas e pretos

O algoritmo tricolor é a base do mark-and-sweep concorrente:

• Branco: Objeto potencialmente não alcançável (candidato a coleta).
• Cinza: Objeto alcançável, mas cujos filhos ainda não foram varridos.
• Preto: Objeto alcançável e completamente varrido.

package main

import "fmt"

// Representação conceitual do estado tricolor
type Color int

const (
    White Color = iota
    Gray
    Black
)

type Object struct {
    color  Color
    refs   []*Object
    data   []byte
}

func markGray(obj *Object) {
    if obj.color == White {
        obj.color = Gray
    }
}

func scanGray(obj *Object) {
    for _, ref := range obj.refs {
        if ref.color == White {
            ref.color = Gray
        }
    }
    obj.color = Black
}

func main() {
    a := &Object{color: White, data: make([]byte, 1024)}
    b := &Object{color: White, data: make([]byte, 512)}
    a.refs = append(a.refs, b)

    // Início da marcação a partir de 'a'
    markGray(a)
    scanGray(a) // a fica preto, b fica cinza
    scanGray(b) // b fica preto

    fmt.Printf("a=%d (Black=%d), b=%d (Black=%d)\n", a.color, Black, b.color, Black)
}

3.2. Processo de varredura a partir das raízes (stacks, globais, heap)

As raízes do GC incluem:
- Stacks de todas as goroutines
- Variáveis globais
- Registradores e ponteiros em frames de chamada

package main

import (
    "fmt"
    "runtime"
)

var globalCache = make(map[string]*Data)

type Data struct {
    ID   int
    Name string
}

func processData() {
    local := &Data{ID: 1, Name: "local"} // No stack
    globalCache["key"] = &Data{ID: 2, Name: "global"} // No heap via global

    fmt.Println(local.ID)
    // GC varre stack (local) e globais (globalCache)
    runtime.GC()
}

func main() {
    processData()
    // Neste ponto, 'local' não é mais alcançável (stack limpo)
    // 'globalCache' ainda mantém referência heap
}

3.3. Garantia de que objetos alcançáveis não são coletados

O algoritmo tricolor, combinado com write barriers, garante a invariante fundamental: nenhum objeto preto referencia um objeto branco diretamente. Isso previne a coleta de objetos ainda em uso.

4. Controle de Pausa e Latência

4.1. Meta de pausa máxima: < 500µs típico

O GC do Go é projetado para manter pausas STW abaixo de 500 microssegundos na maioria dos cenários. Isso é alcançado através de:
- Trabalho concorrente durante o marking
- Pausas STW extremamente curtas (apenas para configuração e finalização)
- Escalonamento inteligente do trabalho de GC

4.2. Ajuste dinâmico da taxa de trabalho do GC (GC percent)

O Go ajusta automaticamente a frequência do GC baseado na taxa de alocação. O parâmetro GOGC controla o gatilho: quando o heap cresce X% desde o último GC, um novo ciclo é iniciado.

package main

import (
    "fmt"
    "runtime"
    "time"
)

func monitorGC() {
    var stats runtime.MemStats
    for i := 0; i < 5; i++ {
        runtime.ReadMemStats(&stats)
        fmt.Printf("GC cycles: %d, LastGC: %v, PauseTotal: %v\n",
            stats.NumGC,
            time.Unix(0, int64(stats.LastGC)),
            time.Duration(stats.PauseTotalNs))
        time.Sleep(500 * time.Millisecond)
    }
}

func main() {
    // GOGC=100 significa: dispara GC quando heap dobra
    // GOGC=200: dispara quando heap triplica (menos GC, mais memória)
    // GOGC=off: desliga GC (cuidado!)

    go monitorGC()

    // Alocações intensas
    for i := 0; i < 1000; i++ {
        _ = make([]byte, 100*1024) // 100KB
        time.Sleep(1 * time.Millisecond)
    }
}

4.3. Mecanismo de assistência (GC assist) para evitar estouro de heap

Se uma goroutine aloca muito rápido e o GC não consegue acompanhar, o runtime força a goroutine a ajudar na marcação antes de completar a alocação. Isso evita que o heap cresça indefinidamente.

5. Configuração e Monitoramento do GC

5.1. Variável GOGC: ajustando o gatilho de coleta

# Aumenta intervalo entre GCs (menos coleta, mais memória)
GOGC=200 go run main.go

# GC mais agressivo (mais coleta, menos memória)
GOGC=50 go run main.go

# Desliga GC (apenas para debugging!)
GOGC=off go run main.go

5.2. Métricas de runtime: runtime.ReadMemStats, debug.GCStats

package main

import (
    "fmt"
    "runtime/debug"
    "time"
)

func printGCStats() {
    var gc debug.GCStats
    debug.ReadGCStats(&gc)
    fmt.Printf("Último GC: %v\n", gc.LastGC)
    fmt.Printf("Pausas: %v\n", gc.Pause)
    fmt.Printf("Total pausa: %v\n", gc.PauseTotal)
}

func main() {
    for i := 0; i < 5; i++ {
        _ = make([]byte, 50*1024*1024)
        runtime.GC()
        printGCStats()
        time.Sleep(200 * time.Millisecond)
    }
}

5.3. Uso de GODEBUG=gctrace=1 para logs detalhados

GODEBUG=gctrace=1 go run main.go

# Saída típica:
# gc 1 @0.003s 2%: 0.010+0.42+0.008 ms clock, 0.080+0.12/0.31/0.020+0.064 ms cpu, 4->4->2 MB, 5 MB goal, 8 P
# gc 2 @0.005s 3%: 0.008+0.35+0.006 ms clock, 0.064+0.10/0.25/0.016+0.048 ms cpu, 4->4->2 MB, 5 MB goal, 8 P

Interpretação:
- gc 1: número do ciclo
- @0.003s: tempo desde o início do programa
- 2%: fração de CPU usada pelo GC
- 0.010+0.42+0.008 ms: tempos de STW (mark start), marking concorrente, mark termination
- 4->4->2 MB: heap antes, durante e depois do GC
- 5 MB goal: meta de heap para próximo GC

6. Impacto do GC na Performance

6.1. Trade-off entre throughput e latência

GC mais frequente (GOGC baixo) reduz pico de memória mas aumenta overhead. GC menos frequente (GOGC alto) melhora throughput mas pode causar pausas maiores quando ocorre.

6.2. Efeito de alocações excessivas no heap (escapes)

Alocações no heap são mais caras que no stack. Use a flag -gcflags="-m" para identificar escapes:

package main

//go:noinline
func createSlice() []int {
    return make([]int, 1000) // Escapa para heap
}

func main() {
    s := createSlice()
    _ = s
}

go build -gcflags="-m" main.go
# ./main.go:6:14: make([]int, 1000) escapes to heap

6.3. Boas práticas: reutilização de objetos, pools (sync.Pool)

package main

import (
    "fmt"
    "sync"
)

type Buffer struct {
    data []byte
}

var bufferPool = sync.Pool{
    New: func() interface{} {
        return &Buffer{data: make([]byte, 0, 1024)}
    },
}

func processRequest() {
    buf := bufferPool.Get().(*Buffer)
    buf.data = buf.data[:0] // Reset sem realocar
    // ... usar buffer
    bufferPool.Put(buf) // Devolve ao pool
}

func main() {
    for i := 0; i < 1000; i++ {
        processRequest()
    }
    fmt.Println("Objetos reutilizados, menos pressão no GC")
}

7. Casos Avançados e Debugging

7.1. Forçando execução do GC com runtime.GC()

Útil para debugging, mas não use em produção (interrompe o escalonamento natural do GC).

7.2. Identificando vazamentos de memória com pprof e heap profiles

package main

import (
    "net/http"
    _ "net/http/pprof"
    "runtime"
)

func leakingFunction() {
    // Simula vazamento: goroutines nunca finalizam
    ch := make(chan int)
    go func() {
        <-ch // Nunca recebe
    }()
}

func main() {
    go func() {
        http.ListenAndServe("localhost:6060", nil)
    }()

    for i := 0; i < 1000; i++ {
        leakingFunction()
    }
    runtime.GC()
    select {} // Bloqueia
}

# Analisar heap
go tool pprof http://localhost:6060/debug/pprof/heap
# (pprof) top
# (pprof) list leakingFunction

7.3. Limitações: GC não lida com caches externos ou CGO

O GC do Go gerencia apenas memória alocada pelo runtime Go. Memória alocada via CGO ou caches externos (como Redis, memcached) não são rastreados:

/*
#include <stdlib.h>
*/
import "C"
import "unsafe"

func allocateCGO() {
    ptr := C.malloc(1024) // Memória não gerenciada pelo GC
    // Precisa liberar manualmente:
    C.free(unsafe.Pointer(ptr))
}

Referências

• Documentação oficial do GC no Go — Guia completo sobre o garbage collector, incluindo design e implementação.
• Proposal: Eliminate STW stack re-scanning (Go 1.8) — Proposta técnica detalhando otimizações que reduziram pausas STW.
• GopherCon 2018: The Go GC - How does it work? — Palestra técnica de Richard Hudson sobre os detalhes internos do GC.
• Garbage Collection in Go (Ardan Labs) — Série de artigos práticos sobre semântica e impacto do GC.
• Profiling Go Programs (Go Blog) — Tutorial oficial sobre uso

de pprof e heap profiles para debugging de memória.

Conclusão

O garbage collector do Go é uma peça fundamental do runtime, projetado para oferecer baixa latência com pausas tipicamente abaixo de 500µs. Seu algoritmo mark-and-sweep concorrente com tricolor marking permite que a coleta aconteça em paralelo com a execução das goroutines, enquanto as write barriers garantem consistência sem pausas longas.

Compreender como o GC funciona — desde os gatilhos baseados no crescimento do heap até o mecanismo de assistência — permite escrever código mais eficiente. Ajustar GOGC, monitorar métricas com runtime.ReadMemStats e GODEBUG=gctrace=1, e utilizar boas práticas como sync.Pool e minimizar escapes para heap são estratégias essenciais para reduzir a pressão sobre o coletor.

Embora o GC seja automático e eficiente, ele não é uma solução mágica. Vazamentos de memória ainda podem ocorrer com goroutines órfãs, referências circulares não coletadas ou alocações via CGO. Ferramentas como pprof e heap profiles são indispensáveis para identificar esses problemas.

Em resumo, o garbage collector do Go equilibra produtividade do desenvolvedor com performance em produção. Conhecer seus mecanismos internos transforma o GC de uma "caixa preta" em um aliado na construção de sistemas confiáveis e eficientes.