Busque em todas as páginas da documentação
Go é uma linguagem com coleta de lixo e semântica de valor por padrão. Variáveis vivem em registros de ativação que o compilador pode colocar na pilha, no heap ou em armazenamento estático - mas você raramente escolhe onde. Em vez disso, você escolhe tipos: valores, ponteiros, slices, maps e interfaces. Esses tipos determinam o comportamento de cópia, o aliasing e o que o runtime deve rastrear para o coletor de lixo.
Esta página é a âncora conceitual para a seção Tipos de Dados e Memória. Fundamentos de Tipos de Dados mostra a sintaxe do dia a dia; os artigos sobre slices, maps, interfaces e channels explicam as representações do runtime. Aqui você aprende por que Go parece "passagem por valor", o que "tipo de referência" realmente significa em Go e como isso difere do modelo de memória de concorrência separado do Go (regras de happens-before para goroutines).
Pense em uma variável Go como uma caixa nomeada que contém um valor de um determinado tipo. A atribuição copia os bits que constituem o valor (para a maioria dos tipos). Chamar uma função passa uma cópia do argumento, a menos que o tipo do parâmetro seja um ponteiro, caso em que a cópia é o valor do ponteiro (um endereço), não uma cópia profunda do struct apontado.
Go não expõe malloc/free ou transferência de propriedade no estilo Rust. A vida útil da memória é limitada pelo escopo mais a alcançabilidade: quando o último ponteiro para um objeto de heap desaparece, o GC o coleta. Isso é um contrato diferente de "este valor foi movido e a ligação antiga é inválida".
Pilha (stack) e heap são locais de implementação, não palavras-chave da linguagem. Variáveis locais que não escapam de uma função geralmente vivem na pilha da goroutine. Valores cujos endereços sobrevivem ao frame (ponteiros retornados, closures capturando locais, armazenando ponteiros em globais) são movidos para o heap. Você não anota isso; go build -gcflags=-m relata o que o compilador decidiu.
Vários tipos embutidos são semelhantes a referência, mas ainda assim passados por valor: um slice é um pequeno cabeçalho (ponteiro, comprimento, capacidade) copiado na atribuição; maps e channels são descritores que apontam para estruturas do runtime. Copiar o cabeçalho duplica o manipulador, não os dados de apoio - duas variáveis podem observar o mesmo array ou tabela hash.
A análise de escape é executada por função durante a compilação. Se o compilador não puder provar que o endereço de um valor não vaza, ele escapa para o heap. Gatilhos comuns de escape: retornar &local, atribuir &local a uma interface{}, anexar &local a um slice de ponteiros, ou capturar uma variável em uma goroutine que pode sobreviver ao frame.
frame do chamador frame do chamado
┌─────────────┐ ┌─────────────┐
│ s := []int │ cópia hdr │ fn(s []int) │
│ {1,2,3} │ ─────────► │ usa cabeçalho │
└──────┬──────┘ └─────────────┘
│
▼
array de apoio (heap ou pilha - o compilador decide)
A semântica de valor brilha no design de API: time.Time, structs pequenos e IDs são copiados de forma barata e reduzem a mutação oculta. A semântica de ponteiro troca a cópia por estado compartilhado: *Config mutado em um pacote afeta todos os detentores desse ponteiro. Slices ficam no meio: o cabeçalho é copiado, o array de apoio é compartilhado até que append realoque.
O modelo de memória de concorrência do Go (documentado em go.dev/ref/mem) é ortogonal à pilha/heap. Ele define quais leituras e escritas são permitidas entre goroutines através de sincronização: operações de canal, sync.Mutex, sync/atomic e sync.Once estabelecem arestas happens-before. Uma race condition é duas goroutines acessando a mesma memória, com pelo menos uma escrita, sem sincronização. O detector de race as encontra em tempo de execução; a análise de escape não.
| Abordagem | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| Passar struct por valor | Propriedade clara, sem nil, menos races | Custo de cópia para structs grandes | Registros imutáveis pequenos, enums, coordenadas |
Passar *T | Instância compartilhada única, mutação in-place | Verificações de nil, aliasing, risco de race | Configurações grandes, builders, parsers com estado |
| Cabeçalho de slice por valor | Passagem barata, array de apoio compartilhado | Surpresas de aliasing de subslice | Coleções, buffers, I/O de streaming |
Descritor map/chan | Maps compartilhados idiomáticos e sinalização | Não seguro para races em maps não sincronizados | Pipelines concorrentes com sincronização adequada |
Micro-otimizar "manter na pilha" sem profiling geralmente é um esforço desperdiçado. O Go moderno inlines objetos pequenos e o GC Green Tea (padrão em Go 1.26) reduz a sensibilidade a pausas para muitas cargas de trabalho. Quando perfis de alocação mostram caminhos quentes, as correções são frequentemente: reutilizar buffers com sync.Pool, pré-alocar slices (make([]T, 0, n)), passar ponteiros apenas onde necessário ou reduzir o boxing para interface{}.
Valores zero são importantes: slices nil e maps nil se comportam de forma diferente (escrever em um map nil causa pânico; anexar a um slice nil funciona). Interfaces que contêm ponteiros nil tipados não são iguais a uma interface nil - um bug de produção comum coberto em Interface Nil vs Ponteiro Nil.
Para serviços, a semântica de valor nas fronteiras de domínio (retornar cópias, DTOs imutáveis) mais ponteiros apenas dentro de pacotes de alto desempenho é um padrão duradouro. Combine isso com o detector de race em CI e disciplina de mutex/canal de Fundamentos de Concorrência.
new(T) e &T{} ainda podem ser alocados na pilha se não escaparem.*.go.dev/ref/mem é sobre visibilidade de goroutine (happens-before), não sobre posicionamento de alocação.copy(dst, src) ou append para um novo slice podem copiar elementos; a atribuição apenas copia o cabeçalho.Sempre por valor. Se o parâmetro for *T, o valor copiado é o ponteiro (endereço), não o struct em si. Mutações através desse ponteiro são visíveis para todo o código que compartilha o mesmo endereço.
A análise do compilador que decide se o armazenamento de uma variável deve sobreviver à sua função declarante e, portanto, deve ser alocado no heap.
Use receptores de ponteiro quando os métodos mutam o estado, quando o struct é grande o suficiente para que a cópia prejudique o desempenho, ou quando a consistência exige todos os métodos em *T. Receptores de valor são adequados para tipos imutáveis pequenos e evitam mutação acidental.
Variáveis de map são descritores passados por valor. A atribuição ou passagem para uma função copia o descritor, não a tabela de buckets. Ambas as cópias se referem aos mesmos dados do map.
nil. Desreferenciar sem uma verificação de nil causa pânico. O valor zero de *int é nil, não um ponteiro para zero.
São tópicos separados. O posicionamento da alocação é tempo de compilação + GC; o modelo de memória governa quais leituras/escritas entre goroutines são definidas quando você usa primitivas de sincronização ou canais.
Se o ponteiro escapar da função, o compilador aloca o local no heap para que ele permaneça válido após o retorno. Se ele não escapar, o ponteiro pode se referir ao armazenamento da pilha que só é válido enquanto o frame estiver ativo.
Atribuir um valor de interface copia o par de palavras da interface (tipo + ponteiro de dados). Valores pequenos podem viver inline na palavra de dados; valores maiores vivem em outro lugar e a interface aponta para eles.
go build -gcflags=-m registra as decisões de escape. Perfis de CPU e alocação (pprof) mostram onde o custo do runtime realmente se encontra - use-os antes de reescrever tipos.
Frequentemente sim para objetos minúsculos que não escapam, pois a alocação no heap atinge o alocador e a contabilidade do GC. A diferença varia por versão do Go e carga de trabalho; meça em vez de assumir.
Não. Cada goroutine tem sua própria pilha (crescida conforme necessário). O compartilhamento ocorre através de objetos de heap, globais ou acesso sincronizado à memória que ambos referenciam.
A cópia do struct duplica cada campo. O cabeçalho do campo slice é copiado, então ambos os structs veem o mesmo array de apoio até que um lado anexe além da capacidade e realoque.
-gcflags=-mVersões de Pilha: Esta página foi escrita para Go 1.26.x (GC Green Tea padrão, modernizadores go fix - verificar patch na compilação), chi (última versão - verificar na compilação), gin (última versão - verificar na compilação), echo (última versão - verificar na compilação), google.golang.org/grpc (última versão - verificar na compilação), sigs.k8s.io/controller-runtime (última versão - verificar na compilação), kubebuilder (última versão - verificar na compilação), tinygo (última versão - verificar alvos de placa na compilação), wazero (última versão - verificar na compilação) e golangci-lint (última versão - verificar conjunto de linters na compilação).
Revisado por Chris St. John·Última atualização: 19 de jul. de 2026