DEV Community: Jean Grijp

Table-Driven Tests e Paralelismo

Jean Grijp — Wed, 21 Oct 2026 12:41:10 +0000

Em Go, a convenção para testar uma função com vários casos é montar uma tabela de entradas e resultados esperados e percorrê-la com um loop. É o padrão chamado de table-driven tests. Junto com subtestes (t.Run) e execução paralela (t.Parallel), ele cobre cenários felizes, casos extremos e caminhos de erro em uma função só, e a suíte roda em uma fração do tempo sequencial.

Neste texto você vai ver a anatomia desse padrão, o que o t.Parallel() faz por dentro e a armadilha de captura da variável de iteração, que durante mais de uma década fez testes paralelos passarem sem testar os casos que deviam.

O problema dos testes repetitivos

Digamos que você implementou uma função de cálculo de desconto. Escrevendo um teste para cada cenário, o arquivo fica assim:

// Abordagem prolixa e difícil de manter
func TestCalcularDesconto_ClienteNovo(t *testing.T) {
    got := CalcularDesconto(100.0, "NOVO")
    if got != 0.0 {
        t.Errorf("esperava 0.0, recebeu %f", got)
    }
}

func TestCalcularDesconto_ClienteVIP(t *testing.T) {
    got := CalcularDesconto(100.0, "VIP")
    if got != 15.0 {
        t.Errorf("esperava 15.0, recebeu %f", got)
    }
}

func TestCalcularDesconto_ClientePremium(t *testing.T) {
    got := CalcularDesconto(100.0, "PREMIUM")
    if got != 20.0 {
        t.Errorf("esperava 20.0, recebeu %f", got)
    }
}

Cada caso novo duplica o corpo da função, exige um nome longo e repete a asserção. Se a assinatura de CalcularDesconto mudar, você altera dezenas de funções espalhadas pelo arquivo.

A anatomia de um table-driven test

O jeito idiomático separa os dados do teste da lógica de asserção. Uma tabela, que é um slice anônimo de structs, guarda as entradas e os resultados esperados, e um loop executa tudo com o mesmo código:

A estrutura tem quatro partes: a tabela, o loop sobre ela, um subteste por caso e a asserção.

func TestOperacao(t *testing.T) {
    // 1. Definição da tabela de casos
    tests := []struct {
        name    string  // Descrição legível do cenário
        input   int     // Parâmetro de entrada
        want    int     // Resultado esperado
        wantErr bool    // Indica se esperamos um erro neste caso
    }{
        {
            name:    "número positivo par",
            input:   4,
            want:    2,
            wantErr: false,
        },
        {
            name:    "número ímpar",
            input:   5,
            want:    0,
            wantErr: true,
        },
    }

    // 2. Iteração sobre a tabela
    for _, tc := range tests {
        // 3. Execução em subteste isolado
        t.Run(tc.name, func(t *testing.T) {
            got, err := Operacao(tc.input)

            // 4. Asserção padronizada
            if (err != nil) != tc.wantErr {
                t.Fatalf("Operacao(%d) erro = %v, esperava erro? %v", tc.input, err, tc.wantErr)
            }
            if got != tc.want {
                t.Errorf("Operacao(%d) = %d; esperado = %d", tc.input, got, tc.want)
            }
        })
    }
}

Por que uma struct anônima ([]struct{...})? Ela só existe dentro da função de teste, então não polui o pacote com tipos que ninguém mais usa. Adicionar um cenário vira acrescentar uma linha de valores. E os campos nomeados (name: "...", input: ...) deixam claro o que cada valor significa, sem depender da posição.

Subtestes com `t.Run()`

O t.Run(name, func(t *testing.T)) chegou no Go 1.7 e mudou a forma como o Go reporta resultados. Cada volta do loop vira um subteste independente:

O relatório é hierárquico. O runner mostra o teste pai, uma barra e o nome do subteste: TestOperacao/número_positivo_par.
A falha é isolada. Se um subteste falhar com t.Fatalf, só ele é interrompido. O loop continua e os outros casos da tabela são avaliados.
Dá para rodar um cenário só pelo terminal, com uma expressão regular na flag -run:

# Executa apenas o subteste de número ímpar
go test -v -run TestOperacao/número_ímpar

`t.Errorf` ou `t.Fatalf`

Use t.Fatalf quando continuar não faz sentido. Se a função devia devolver um objeto e devolveu nil, seguir adiante causaria um panic de ponteiro nulo ao acessar user.Email. O t.Fatalf aborta o subteste atual na hora.

Use t.Errorf quando a execução terminou normalmente, mas o valor final difere do esperado. O teste continua e confere os outros campos da mesma resposta, então você vê todos os erros de uma vez no log.

Execução paralela com `t.Parallel()`

Por padrão, os testes de um pacote Go rodam em sequência. Numa suíte com centenas de testes, ou com parsing de arquivos pesados, criptografia e I/O, isso deixa núcleos da CPU parados.

Chamar t.Parallel() dentro de um subteste instrui o runner a executá-lo em paralelo com os outros testes paralelos:

O ciclo de vida de um teste paralelo

Quando o Go encontra um t.Parallel(), o subteste passa por três fases:

RUN: o subteste começa a executar na goroutine do teste pai.
PAUSE: ao chegar no t.Parallel(), ele pausa na hora, entra na lista de testes paralelos pendentes e libera o loop principal para seguir.
CONT: quando a função pai termina de registrar todos os subtestes e chega ao fim do seu escopo, o runtime acorda os subtestes pausados em goroutines simultâneas, distribuídas entre os núcleos disponíveis.

Dá para ver isso na saída de go test -v:

=== RUN   TestDividir_TableDriven
=== PAUSE TestDividir_TableDriven
=== CONT  TestDividir_TableDriven
=== RUN   TestDividir_TableDriven/positivo
=== PAUSE TestDividir_TableDriven/positivo
=== RUN   TestDividir_TableDriven/negativo
=== PAUSE TestDividir_TableDriven/negativo
=== CONT  TestDividir_TableDriven/negativo
=== CONT  TestDividir_TableDriven/positivo
--- PASS: TestDividir_TableDriven/positivo (0.00s)
--- PASS: TestDividir_TableDriven/negativo (0.00s)
PASS

Controlando o paralelismo

O número máximo de testes paralelos simultâneos é controlado pela flag -parallel. O padrão é o valor de GOMAXPROCS, que normalmente é o número de núcleos da CPU:

# Permite até 16 testes paralelos simultâneos
go test -parallel=16 ./...

A armadilha da variável de loop

Durante mais de dez anos, combinar for ... range com t.Parallel() foi fonte de um dos bugs mais traiçoeiros do Go:

O código perigoso é este:

// Comportamento bugado em Go 1.21 e anteriores
for _, tc := range tests {
    t.Run(tc.name, func(t *testing.T) {
        t.Parallel() // O subteste pausa aqui

        // Quando for retomado, qual é o valor de tc?
        got := Processar(tc.input)
        if got != tc.want {
            t.Errorf(...)
        }
    })
}

Antes do Go 1.22, a variável tc era alocada uma única vez para o loop inteiro. A cada iteração o Go só sobrescrevia o mesmo endereço de memória com o próximo item.

O t.Parallel() pausa a goroutine do subteste, e o loop principal continua correndo até o fim da tabela. Quando os subtestes acordam, todos enxergam o valor da última iteração. O teste reporta sucesso em todos os casos, mas na prática rodou o último caso várias vezes e ignorou os primeiros.

As duas soluções

Em Go 1.21 e anteriores, a saída é redeclarar a variável dentro do loop, o que cria uma cópia nova a cada volta:

for _, tc := range tests {
    tc := tc // Cria uma cópia local isolada na stack
    t.Run(tc.name, func(t *testing.T) {
        t.Parallel()
        // Agora tc aponta para a cópia segura
        got := Processar(tc.input)
        ...
    })
}

No Go 1.22 e superiores, a semântica da linguagem mudou: cada iteração do for cria uma nova instância da variável por padrão. A linha tc := tc deixou de ser necessária, e essa classe de falha desapareceu.

Dica: se você mantém uma biblioteca de código aberto que ainda dá suporte ao Go 1.20 ou 1.21, deixe a linha tc := tc explícita. Assim a suíte continua correta em qualquer versão do compilador.

Um exemplo completo

Vamos montar uma suíte para um validador de transações financeiras, com erros sentinela e t.Cleanup().

O código de negócio, em transacao.go:

package financeiro

import (
    "errors"
    "fmt"
)

var (
    ErrValorInvalido       = errors.New("o valor da transação deve ser positivo")
    ErrContaInvalida       = errors.New("número de conta de origem ou destino inválido")
    ErrLimiteUltrapassado  = errors.New("valor excede o limite diário da conta")
)

type Transacao struct {
    ContaOrigem  string
    ContaDestino string
    Valor        float64
}

// ValidarTransacao aplica as regras de conformidade bancária.
func ValidarTransacao(t Transacao, limiteDiario float64) error {
    if t.Valor <= 0 {
        return ErrValorInvalido
    }
    if len(t.ContaOrigem) < 5 || len(t.ContaDestino) < 5 {
        return ErrContaInvalida
    }
    if t.ContaOrigem == t.ContaDestino {
        return fmt.Errorf("%w: conta de origem idêntica ao destino", ErrContaInvalida)
    }
    if t.Valor > limiteDiario {
        return ErrLimiteUltrapassado
    }
    return nil
}

A suíte, em transacao_test.go. O loop abaixo assume Go 1.22 ou superior; em versões anteriores, acrescente tc := tc no início do corpo do for.

package financeiro_test

import (
    "errors"
    "testing"

    "meu-modulo/financeiro"
)

func TestValidarTransacao(t *testing.T) {
    t.Parallel() // A suíte pai roda em paralelo com outras do pacote

    // Tabela abrangente de cenários de teste
    tests := []struct {
        name         string
        transacao    financeiro.Transacao
        limiteDiario float64
        wantErr      bool
        expectedErr  error
    }{
        {
            name: "transação regular aprovada",
            transacao: financeiro.Transacao{
                ContaOrigem:  "12345-6",
                ContaDestino: "98765-4",
                Valor:        150.00,
            },
            limiteDiario: 1000.00,
            wantErr:      false,
            expectedErr:  nil,
        },
        {
            name: "transação com valor zero",
            transacao: financeiro.Transacao{
                ContaOrigem:  "12345-6",
                ContaDestino: "98765-4",
                Valor:        0.00,
            },
            limiteDiario: 1000.00,
            wantErr:      true,
            expectedErr:  financeiro.ErrValorInvalido,
        },
        {
            name: "transação com valor negativo",
            transacao: financeiro.Transacao{
                ContaOrigem:  "12345-6",
                ContaDestino: "98765-4",
                Valor:        -50.00,
            },
            limiteDiario: 1000.00,
            wantErr:      true,
            expectedErr:  financeiro.ErrValorInvalido,
        },
        {
            name: "conta de origem com menos de 5 dígitos",
            transacao: financeiro.Transacao{
                ContaOrigem:  "123",
                ContaDestino: "98765-4",
                Valor:        100.00,
            },
            limiteDiario: 1000.00,
            wantErr:      true,
            expectedErr:  financeiro.ErrContaInvalida,
        },
        {
            name: "transferência para a mesma conta",
            transacao: financeiro.Transacao{
                ContaOrigem:  "12345-6",
                ContaDestino: "12345-6",
                Valor:        100.00,
            },
            limiteDiario: 1000.00,
            wantErr:      true,
            expectedErr:  financeiro.ErrContaInvalida,
        },
        {
            name: "valor excede o limite diário",
            transacao: financeiro.Transacao{
                ContaOrigem:  "12345-6",
                ContaDestino: "98765-4",
                Valor:        1500.00,
            },
            limiteDiario: 1000.00,
            wantErr:      true,
            expectedErr:  financeiro.ErrLimiteUltrapassado,
        },
    }

    for _, tc := range tests {
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel() // Cada subteste executa em paralelo

            // t.Cleanup executa garantidamente no final deste subteste
            t.Cleanup(func() {
                // Ideal para fechar arquivos, resetar variáveis ou limpar caches locais
            })

            err := financeiro.ValidarTransacao(tc.transacao, tc.limiteDiario)

            // 1. Verificação da ocorrência de erro
            if (err != nil) != tc.wantErr {
                t.Fatalf("ValidarTransacao() erro = %v, esperava erro? %v", err, tc.wantErr)
            }

            // 2. Verificação precisa do tipo/causa do erro com errors.Is
            if tc.expectedErr != nil && !errors.Is(err, tc.expectedErr) {
                t.Errorf("ValidarTransacao() erro retornado = %v, esperava conter = %v", err, tc.expectedErr)
            }
        })
    }
}

Checklist antes de dar a suíte por concluída

Compare erros com errors.Is, nunca por texto. Um if err.Error() == "texto" quebra na primeira vez que alguém reescrever a mensagem. Valide contra o erro sentinela com errors.Is(err, ErrAlvo).
Rode com o detector de corridas na integração contínua:

   go test -race ./...

Se os subtestes paralelos acessarem uma variável global ou outro recurso compartilhado sem proteção, o detector aponta as linhas em conflito.

Dê nomes descritivos aos subtestes. O campo name deve dizer o que o cenário cobre e por quê, por exemplo "idade negativa deve retornar erro de validação".
Não compartilhe estado entre testes paralelos. Um teste com t.Parallel() não deve alterar variáveis globais, tabelas de banco sem transação isolada ou o diretório de trabalho.
Chame t.Helper() na primeira linha de qualquer função auxiliar de asserção. Assim o Go reporta a linha do teste que falhou, e não a linha dentro do utilitário.

Beba Água <3

go #golang #testing #tabledriventests #testesunitarios #paralelismo #concorrencia #backend #braziliandevs

6 Go Libraries That Completely Transformed Software Development in 2025

Jean Grijp — Tue, 30 Sep 2025 19:24:54 +0000

Goroutines, threads e o caos coordenado do Go Scheduler.

Jean Grijp — Thu, 24 Apr 2025 23:29:30 +0000

Fala dev, estou compartilhando mais um doc que criei no Obsidian, espero que a leitura te ajude de alguma forma. Lembrando que estou aprendendo sobre o assunto, então se tu encontrar algo estranho ou errado, bora trocar ideia, comenta o post com educação e bora codar em Go.

O que é uma Thread?

Uma thread é uma unidade de execução dentro de um processo. É o que permite que um programa realize múltiplas tarefas aparentemente ao mesmo tempo. Em sistemas tradicionais, cada thread possui sua própria stack e é gerenciada pelo sistema operacional, com alto custo de criação e comutação. Em contrapartida, o Go abstrai esse conceito com as goroutines, que são unidades de execução mais leves que threads, gerenciadas pelo runtime do Go, muito mais leves e eficientes para tarefas concorrentes. Mesmo assim, entender o conceito de thread continua sendo útil, porque é a base sobre a qual a concorrência moderna foi construída.

Cada thread, no contexto de programação, tem a sua própria call stack. Isso significa que quando você cria uma nova thread, o sistema operacional ou o runtime da linguagem aloca uma nova região de memória exclusiva pra ela, onde vai empilhar as chamadas de função feitas dentro dessa thread. Essa pilha é isolada das demais threads: se duas threads estiverem rodando ao mesmo tempo e ambas chamarem uma função chamada processarDados(), cada uma delas vai ter a sua própria versão empilhada de processarDados() na sua respectiva stack. Elas não brigam pela mesma memória porque estão cada uma vivendo seu mundinho solitário de execução.

A stack da thread é onde ficam armazenados os dados temporários da execução: parâmetros de função, variáveis locais e o endereço de retorno — ou seja, pra onde voltar quando a função acabar. Quando uma função é chamada, o frame é empilhado na stack da thread atual. Quando ela retorna, o frame é removido. É uma dança organizada de entrada e saída de contextos de execução, sempre seguindo o modelo LIFO: a última chamada é a primeira a sair.

Agora, por que isso importa? Porque se você fizer besteira dentro de uma thread — tipo criar recursão infinita ou entupir a execução com chamadas profundas — só a stack daquela thread vai explodir. As outras threads, felizes e inconscientes, continuam rodando como se nada tivesse acontecido.

E em Go? A coisa muda um pouco, porque Go não usa threads diretamente. Ele usa goroutines, que são programaticamente muito mais leves, mas o princípio é parecido: cada goroutine tem sua própria stack separada, e ela funciona da mesma forma que a stack de uma thread — só que com o charme extra de ser pequena, flexível e controlada pelo runtime em vez do sistema operacional.

Go Scheduler

No Go, o agendador de goroutines — chamado carinhosamente de Go scheduler — é o componente do runtime responsável por decidir qual goroutine roda, em qual thread, e quando. E aqui vai o plot twist: o Go não cria uma thread nova do sistema operacional pra cada goroutine. Se fizesse isso, seria como contratar um funcionário novo pra cada planilha que você abre — caro, lento, e só útil se você quiser falir seu computador.

Em vez disso, o Go cria um pequeno grupo de threads reais (do sistema operacional), chamadas de M (machine threads), e distribui as goroutines entre elas. Essas goroutines são gerenciadas inteiramente pelo runtime da linguagem, o que as torna semelhantes às chamadas green threads ou user-space threads — embora com diferenças importantes: no Go, múltiplas goroutines são mapeadas para múltiplas threads, não apenas uma.

Cada M precisa estar associada a um P, de Processor, que é uma unidade lógica do Go usada para coordenar a execução de código Go. O modelo de execução é conhecido como G:M:P, onde:

G é a goroutine (o que será executado),
M é a thread do sistema operacional (o que executa),
P é o processador lógico (o que permite que a execução ocorra).

Quer um exemplo? Suponha que seu programa tenha GOMAXPROCS=4. Isso quer dizer que o runtime do Go vai criar 4 P — ou seja, vai usar até 4 núcleos da CPU simultaneamente. Esses P’s são os “slots de execução”: cada P permite que uma M execute goroutines, empilhando e desempilhando chamadas dentro da stack exclusiva da goroutine. O runtime coordena essa execução, e as threads (M) vão pegando e executando as goroutines disponíveis.

O agendador decide quando uma goroutine deve parar de rodar e outra deve assumir o controle. Isso acontece, por exemplo, quando uma goroutine realiza uma operação bloqueante (como I/O), ou atinge um ponto seguro de preempção — como loops longos ou chamadas a funções específicas. Nesse momento, o scheduler salva o estado da goroutine (inclusive a stack!) e coloca outra no lugar, como quem troca um funcionário sonolento por outro animado na linha de produção.

O mais divertido (ou caótico, se você for o tipo de dev que gosta de controle absoluto) é que tudo isso é transparente. Você escreve um código com go minhaFuncao(), e de repente tem mil goroutines rodando “em paralelo” — mesmo que elas estejam dividindo umas poucas threads reais por trás das cortinas. Cada goroutine mantém sua própria stack, pequena e dinâmica, e o runtime gerencia o show: cresce stacks sob demanda, troca contextos, e faz você parecer um gênio da concorrência mesmo sem saber quantos M, P e G estão trabalhando nos bastidores.

Mas o que é esse tal de `P`?

No modelo de agendamento do Go, o P (de Processor) representa uma unidade lógica de execução controlada pelo runtime. Ele não é um thread nem uma goroutine, mas sim o intermediário essencial que gerencia o agendamento de goroutines e fornece contexto para que o código Go seja executado por uma thread (M). Cada P possui uma fila local de goroutines prontas para execução, conhecida como run queue. O runtime sempre tenta consumir essa fila local primeiro, o que melhora o desempenho ao evitar sincronização com outras estruturas globais e aproveita melhor o cache da CPU.

Quando uma thread (M) está associada a um P, ela pode executar goroutines da run queue daquele P. Caso essa fila esteja vazia, o runtime tenta buscar novas goroutines da fila global, ou até mesmo roubar goroutines de outro P, numa estratégia conhecida como work stealing. Esse mecanismo evita desequilíbrios entre processadores lógicos e mantém a carga distribuída mesmo em cenários de concorrência intensa.

O número de Ps ativos é determinado por GOMAXPROCS, o que significa que, mesmo que existam milhares de goroutines, apenas um número limitado (igual ao de Ps) pode estar executando código Go simultaneamente. As demais ficam na fila aguardando sua vez.

Chamadas bloqueantes (syscalls) e uso inteligente de threads (`M`)

Em Go, uma goroutine pode, eventualmente, fazer uma chamada ao sistema operacional que bloqueia a thread. Isso acontece em situações comuns, como chamadas de rede, leitura de arquivos ou qualquer operação de I/O via syscall. Quando isso ocorre, a thread (M) que estava executando a goroutine fica bloqueada até que a operação termine.

Agora vem a parte crítica: se o runtime simplesmente deixasse o P associado a essa M bloqueada, o programa perderia a capacidade de executar novas goroutines naquele slot de execução — o que resultaria em desperdício de recursos e perda de desempenho. Para evitar isso, o Go runtime desassocia o P da thread bloqueada (M) e o entrega a outra thread que esteja disponível. Dessa forma, o P continua executando outras goroutines prontas na fila, e o programa segue rodando com eficiência, mesmo durante operações de I/O demoradas. Se não houver nenhuma M disponível no momento, o runtime pode criar uma nova thread real do sistema operacional. Isso é feito de maneira controlada, com limites internos, para evitar que o programa crie um número excessivo de threads e sobrecarregue o sistema.

Essa estratégia de desacoplamento entre o agendamento das goroutines e o bloqueio do sistema operacional é um dos principais motivos pelos quais o Go consegue lidar tão bem com aplicações altamente concorrentes — como servidores HTTP, workers de fila, ou qualquer sistema com múltiplas operações simultâneas que dependem de I/O. Além disso, é importante destacar que o Go diferencia bem código Go puro (que pode ser interrompido, agendado, migrado entre threads) de código que envolve chamadas nativas ou externas, onde o controle de execução passa, mesmo que temporariamente, para o SO.

Um pouco mais sobre stacks dinâmicas das goroutines

Uma das características mais importantes das goroutines é o uso de stacks dinâmicas, que são controladas inteiramente pelo runtime do Go. Diferente das threads tradicionais do sistema operacional que geralmente alocam uma stack fixa de 1 MB ou mais, cada goroutine começa com uma stack extremamente pequena, geralmente apenas 2 KB. Essa escolha reduz drasticamente o custo de criação de novas goroutines e é um dos principais motivos pelos quais é possível criar milhares ou até milhões de goroutines em uma única aplicação Go sem comprometer a memória do sistema. A medida que a execução da goroutine avança, se o espaço da stack se tornar insuficiente (por exemplo, devido a chamadas de função aninhadas ou uso intensivo de variáveis locais), o runtime detecta essa situação e realoca a stack em uma região maior de memória, copiando seu conteúdo atual e ajustando os ponteiros automaticamente. Esse processo é transparente para o desenvolvedor e não exige nenhuma intervenção manual. Além disso, o runtime é capaz de reduzir o tamanho da stack de uma goroutine quando percebe que ela não precisa mais de tanta memória. Essa flexibilidade bidirecional permite uma gestão de memória muito mais eficiente do que stacks fixas, e ajuda a manter a escalabilidade e responsividade da aplicação.

Vale lembrar que essa operação de crescimento (ou encolhimento) da stack pode ter custo de desempenho pontual, especialmente se ocorrer com frequência. Por isso, em cenários críticos de performance, é possível otimizar o uso da stack escrevendo funções com profundidade de chamada controlada e evitando estruturas muito grandes em variáveis locais.

Como o Go lida com preempção, ou seja, como ele lida com aquelas goroutines folgadas que decidem nunca mais sair da CPU?

O agendador do Go precisa garantir que nenhuma goroutine fique se achando a dona da CPU. Pra isso, existe o conceito de preempção, que basicamente é o runtime dizendo “chega, tua vez acabou, deixa o coleguinha brincar”. Só que o Go não faz isso de forma brutal, como alguns sistemas operacionais que simplesmente pausam a thread no meio de qualquer instrução. Em vez disso, o Go usa o modelo de preempção cooperativa, o que significa que ele só pode interromper a execução de uma goroutine em pontos seguros do código, lugares estrategicamente definidos onde o runtime sabe que pode pausar sem quebrar tudo.

Esses pontos seguros (ou safe points, se você quiser parecer mais chique) são colocados pelo compilador em lugares como o início de loops, chamadas de função ou outras instruções que o runtime monitora. A ideia é evitar que uma goroutine fique rodando pra sempre sem dar chance pras outras, tipo aquele colega de reunião que não larga o microfone.

Antes do Go 1.14, isso era um problema sério. Se uma goroutine entrasse num loop longo sem fazer nenhuma chamada externa, ela podia simplesmente monopolizar um núcleo da CPU e impedir que outras goroutines rodassem. Era como ter um funcionário que esqueceu de sair pra almoço e não deixa ninguém mais usar a sala de reunião. A partir do Go 1.14, o runtime ganhou um superpoder: o compilador passou a inserir instruções especiais nos loops e outros trechos críticos, permitindo que o agendador dê aquele “tapinha no ombro” da goroutine e diga: "tempo esgotado, agora deixa o próximo". Quando isso acontece, o estado da execução é salvo e outra goroutine assume a execução no mesmo P. Esse esquema garante que nenhuma goroutine abuse do tempo de CPU e ajuda o Go a manter o show rodando suave — sem threads explodindo, sem pausas indesejadas, e sem você precisar escrever uma linha de código pra gerenciar isso.

Limitações e armadilhas do Go Scheduler (sim, ele também tem seus dias ruins)

O Go scheduler é ótimo — ele faz muito com pouco: organiza milhares de goroutines com algumas threads reais, empilha, desempilha, redistribui... tudo isso quase sem você notar. Mas ele não é mágico nem infalível. Em algumas situações específicas, ele pode se tornar um gargalo, especialmente quando a arquitetura da aplicação força os limites do modelo G:M:P.

Um dos principais pontos de atenção está no valor de GOMAXPROCS. Como esse valor define quantos Ps existem, ele limita o número de goroutines que podem executar código Go ao mesmo tempo. Se GOMAXPROCS=2, por exemplo, mesmo que você tenha 10 mil goroutines prontas pra rodar, só duas vão de fato executar simultaneamente. As outras ficam esperando na fila. Isso é ótimo pra controle de paralelismo, mas pode gerar filas grandes e latência inesperada se o número de goroutines prontas crescer rápido demais.

Outro fator crítico: o scheduler não tem conhecimento semântico do que suas goroutines estão fazendo. Ele não sabe se a goroutine está processando uma requisição urgente ou só atualizando um cache irrelevante. O escalonamento é feito com base em prontidão, não em prioridade. Isso significa que goroutines com workloads diferentes podem competir igualmente por tempo de execução, o que nem sempre é ideal. Em alguns casos, goroutines importantes podem ser preemptadas por outras menos críticas, impactando a qualidade do serviço.

O scheduler também pode sofrer se você tiver muitas goroutines prontas ao mesmo tempo, mas com uma lógica que exige muita alternância entre elas (ex: milhares de canais se comunicando em alta frequência). Isso pode causar overhead de troca de contexto e pressionar a fila global de goroutines — que, diferente das filas locais dos Ps, exige lock e pode se tornar um ponto de contenção.

Além disso, é comum ver devs criando goroutines demais sem pensar no lifecycle delas. Se você esquece de controlar o tempo de vida de uma goroutine (como não cancelá-la via context, por exemplo), elas continuam vivas, mesmo que não estejam fazendo nada útil. Isso gera acúmulo silencioso: pilhas crescendo, memória sendo usada à toa, e mais carga sobre o agendador.

Por fim, como o Go não tem preempção baseada em tempo real (como certos kernels de SO), uma goroutine que faz uso intensivo de CPU sem pontos de preempção ainda pode gerar starvation (as outras goroutines ficam sem tempo de execução). Isso é raro com as melhorias do Go 1.14+, mas ainda possível se você escrever código que "engole" o processador por muito tempo sem pausas.

chegou até aqui?

Entender como o Go lida com agendamento, preempção, chamadas bloqueantes e stacks minúsculas não só te ajuda a escrever código mais eficiente, como também evita que você saia criando goroutine igual panfleto em semáforo e depois não saiba de onde vem o vazamento de memória. Se esse artigo te ajudou, manda pra aquele(a) amigo(a) que acha que go func() {} é solução mágica pra tudo. E se você encontrou algum erro, manda também, estou aprendendo sobre o tema, e além disso porque o scheduler pode escalar milhares de goroutines, mas eu ainda não escalo múltiplas versões de mim mesmo.

Valeu demais por acompanhar. Até a próxima execução paralela. #Beba_agua.

Go e o Stack Invisível: Como Funções e Goroutines Administram Memória nos Bastidores.

Jean Grijp — Tue, 22 Apr 2025 12:54:21 +0000

Comecei a estudar sobre a Call Stack do Go e percebi que seria legal compartilhar o resultado, então eu espero que esse post ajude a quem estiver aprendendo Go também. Ao longo da explicação dos conceitos, pode ser que eu repita algo que já expliquei, mas a intenção é reforçar o conceito para eliminar possíveis dúvidas, mas claro, sem deixar o texto extremamente repetitivo. beba água.

A stack, ou pilha de execução, é uma estrutura de dados usada internamente pelas linguagens de programação para controlar a ordem de execução das funções. Ela segue uma lógica chamada LIFO, que significa "Last In, First Out" — ou seja, a última função que entrou na pilha é a primeira que vai sair. É como empilhar livros: o último que você colocou em cima é o primeiro que você vai tirar. Essa pilha não é um conceito visual bonitinho só pra programador iniciante se sentir incluído; ela é real, ela mora na memória do processo e serve pra guardar o que está acontecendo a cada momento da execução.

Quando uma função é chamada, o programa empilha um frame, que é como um pacote com informações: quais são os argumentos da função, quais variáveis ela declarou internamente, e — talvez o mais importante — qual o endereço de memória que ele precisa voltar depois que essa função terminar. Assim que a função conclui seu trabalho, esse frame é retirado da Stack, e o controle volta pra função anterior, que estava de braços cruzados esperando isso acontecer.

Esse processo de empilhar e desempilhar acontece de forma automática, você não precisa fazer nada. A não ser que você seja um desenvolvedor em Go querendo entender por que o seu programa explodiu com um stack overflow, o que geralmente significa que uma função chamou a si mesma tantas vezes que a pilha não teve mais espaço pra guardar os frames.

No Go, cada função que você chama também entra na stack, como em qualquer linguagem procedural que não acordou ontem. A diferença está na forma como o Go gerencia essa stack por trás das cortinas. Em vez de criar uma stack grandona e fixa por thread, como acontece em linguagens como C ou Java, o Go tem um modelo mais... econômico. Cada goroutines (que é uma unidade de execução leve, menor que uma thread, e gerenciada pelo runtime do Go) começa com uma stack minúscula, normalmente em torno de 2 KB, isso é ridiculamente pequeno.

Essa stack pequenininha é dinâmica. O que significa isso? Significa que, à medida que a função chama outra função, e assim por diante, o Go percebe quando está ficando apertado e realoca a stack para um espaço maior. Sim, ele literalmente copia a pilha inteira para outro lugar na memória. Parece ineficiente, mas na prática é bem rápido e muito mais econômico do que reservar 1 MB por goroutine só porque você tem sonhos grandes demais. É esse esquema que permite ao Go criar centenas de milhares de goroutines sem mandar sua máquina pro hospital.

Mas nem tudo são flores, como o stack é móvel, o Go precisa tomar muito cuidado com ponteiros. Diferente de C, onde um ponteiro pode apontar pro nada e te causar pesadelos, no Go o runtime cuida de atualizar tudo quando o stack é movido.

Além disso, quando ocorre um erro, como um panic, o Go consegue imprimir um stack trace que mostra exatamente a cadeia de chamadas que levou ao desastre. O stack trace é construído a partir das informações mantidas pelo runtime, que incluem os frames da stack e os metadados de chamadas. Não é super detalhado como um debugger de verdade, mas serve pra você olhar com vergonha e dizer: “é, fui eu mesmo que escrevi essa aberração.”

Como o Go sabe que precisa crescer o stack?

Isso é onde o Go fica metido a esperto. Toda vez que uma função é chamada, o runtime precisa garantir que haja espaço suficiente no stack da goroutine para que a função execute. Isso inclui espaço para variáveis locais, argumentos e o que mais for necessário dentro daquele frame. Só que, lembra? O stack começa ridiculamente pequeno. Pra resolver isso, o compilador do Go insere automaticamente um código de verificação no início de cada função. Isso é conhecido como o famoso stack split check. Traduzindo do Goês para o Idioma dos Mortais: é uma checagem que pergunta "tenho espaço suficiente pra rodar essa função aqui ou não?"

Se a resposta for “sim”, maravilha. A função executa normalmente e ninguém sofre. Se a resposta for “não”, o Go chama uma função especial, newstack(), que realiza o crescimento da pilha. É uma função interna, mas não é chamada como uma função “normal”. O código gerado pelo compilador faz uma chamada especial a essa função em assembly.

Agora vem a parte legal (ou trágica, depende de quanto você gosta de ver seu programa fazendo cópia de memória no meio da execução): essa função newstack() cria uma nova área de memória maior, copia todo o conteúdo da stack atual pra lá, ajusta os ponteiros, e depois continua a execução como se nada tivesse acontecido. É como trocar o chão enquanto você ainda está andando — e torcer pra ninguém perceber.

Isso funciona porque o Go controla todo o ambiente da goroutine. Nenhum ponteiro externo aponta diretamente pro stack (pelo menos, não deveria — o compilador e o garbage collector trabalham pra evitar isso), então é seguro mover tudo sem causar um incêndio na memória. Por isso, o Go consegue crescer stacks conforme a necessidade sem causar overhead constante. Você paga o preço da realocação só quando realmente precisa. Isso também explica por que goroutines são tão leves: elas só consomem o que for necessário, e vão crescendo conforme o uso real, em vez de começar como um trambolho de 1 MB cada uma.

Heap x Stack

O gerenciamento de memória é dividido entre duas regiões principais: a stack e o heap. A stack é usada para armazenar variáveis locais de curta duração, parâmetros de função e tudo que pode ser descartado rapidamente assim que a função termina. Cada vez que uma função é chamada, o Go aloca um pequeno espaço na stack — chamado de stack frame — onde ele guarda todas as informações relacionadas àquela execução. Esse espaço inclui os argumentos passados, variáveis locais e um ponteiro que indica onde a execução deve continuar quando a função retornar. Quando a função termina, esse frame é simplesmente removido da stack, liberando o espaço de forma rápida e eficiente.

A stack no Go é única para cada goroutine. Isso significa que toda goroutine que você cria tem sua própria pilha, independente das outras. Essas stacks são minúsculas por padrão (começam com apenas 2KB), mas têm a habilidade mágica de crescer dinamicamente se for necessário, através de um processo chamado stack splitting. Isso permite que milhares ou até milhões de goroutines coexistam sem fritar sua máquina, o que é uma façanha que linguagens mais ortodoxas como Java só conseguem com oração.

Já o heap é onde moram as variáveis que o compilador acha que vão viver por mais tempo, ou que precisam ser acessadas fora do escopo da função onde nasceram. O Go decide o destino de cada variável usando uma técnica chamada escape analysis, que basicamente responde à pergunta: “essa variável vai vazar do contexto onde foi criada?” Se sim, ela vai direto pro heap. Isso acontece, por exemplo, quando você retorna o ponteiro de uma variável local, ou quando uma função armazena referências em uma estrutura que vai sobreviver à execução atual.

As funções em si — ou seja, o código delas — não vão pra heap nem pra stack. Elas são armazenadas numa região separada da memória chamada text segment, que é onde vive o binário compilado. Quando você chama uma função, o Go basicamente empilha um novo frame na stack da goroutine ativa e pula praquele endereço no text segment. Quando ela termina, ele volta pro ponto anterior e a vida segue.

Esse modelo é extremamente eficiente. Usar a stack como área principal de alocação temporária reduz a carga do garbage collector, que só precisa se preocupar com as variáveis no heap. Mas como nem tudo é perfeito, você ainda precisa estar ciente de quando suas variáveis vão parar lá, pra evitar alocações desnecessárias e gargalos invisíveis de desempenho. E sim, isso significa que às vezes vale a pena olhar os relatórios de escape do compilador — por mais deprimentes que eles sejam.

As funções em Go

Já as funções, diferentemente das variáveis, têm um destino completamente diferente. O código da função em si é armazenado em uma região especial da memória chamada text segment, também conhecida como code segment. Essa parte da memória é onde vive o código executável do programa. Quando você chama uma função, a CPU salta para o endereço correspondente no text segment, e as variáveis que a função usa são empilhadas na stack ou alocadas no heap, dependendo do que o compilador decidir.

Essa arquitetura torna o Go extremamente eficiente para lidar com concorrência e múltiplas goroutines. Cada goroutine tem sua própria stack que começa pequena e pode crescer de forma dinâmica, permitindo que você tenha milhares de tarefas leves rodando ao mesmo tempo. Ao mesmo tempo, a separação clara entre stack, heap e text segment ajuda o compilador a otimizar a execução e o uso de memória de forma bastante eficaz.

Alocação na Stack

package main

import "fmt"

func main() {
    x := 42
    printValue(x)
}

func printValue(val int) {
    fmt.Println(val)
}

Nesse exemplo, a variável x é um valor simples. Ele é passado por valor para a função printValue, e não é retornado, nem usado fora do main. Como nada escapa, o compilador é feliz e aloca tudo isso na stack.

Alocação na Heap

package main

import "fmt"

func main() {
    ptr := createPointer()
    fmt.Println(*ptr)
}

func createPointer() *int {
    x := 42
    return &x
}

Agora temos o mesmo valor, 42, e o mesmo tipo de variável. Mas olha o crime aqui: estamos retornando um ponteiro para uma variável local. A stack de createPointer vai sumir assim que a função retornar, então se x estivesse ali, estaríamos acessando memória morta. O compilador detecta isso e joga x direto no heap, garantindo que ele sobreviva após o retorno.

Consideração final

Se você chegou até aqui, parabéns. Você agora sabe mais sobre a call stack do Go do que 90% das pessoas que colocam "Golang ninja" no LinkedIn. E se em algum momento achou que a stack era só um lugarzinho onde variáveis iam tirar uma soneca, sinto informar que ela é mais parecida com uma república de estudantes: todo mundo entra, ninguém limpa nada, e eventualmente alguém causa um panic e tudo desmorona.

Mas agora você sabe o que está acontecendo por trás das cortinas — ou melhor, das goroutines — e pode finalmente olhar para um stack trace sem chorar (muito). E lembre-se: se algo deu errado, provavelmente foi porque você retornou o ponteiro errado…

DEV Community: Jean Grijp

Table-Driven Tests e Paralelismo

O problema dos testes repetitivos

A anatomia de um table-driven test

Subtestes com `t.Run()`

`t.Errorf` ou `t.Fatalf`

Execução paralela com `t.Parallel()`

O ciclo de vida de um teste paralelo

Controlando o paralelismo

A armadilha da variável de loop

As duas soluções

Um exemplo completo

Checklist antes de dar a suíte por concluída

go #golang #testing #tabledriventests #testesunitarios #paralelismo #concorrencia #backend #braziliandevs

6 Go Libraries That Completely Transformed Software Development in 2025

Goroutines, threads e o caos coordenado do Go Scheduler.

O que é uma Thread?

Go Scheduler

Mas o que é esse tal de `P`?

Chamadas bloqueantes (syscalls) e uso inteligente de threads (`M`)

Um pouco mais sobre stacks dinâmicas das goroutines

Como o Go lida com preempção, ou seja, como ele lida com aquelas goroutines folgadas que decidem nunca mais sair da CPU?

Limitações e armadilhas do Go Scheduler (sim, ele também tem seus dias ruins)

chegou até aqui?

Go e o Stack Invisível: Como Funções e Goroutines Administram Memória nos Bastidores.

Como o Go sabe que precisa crescer o stack?

Heap x Stack

As funções em Go

Alocação na Stack

Alocação na Heap

Consideração final

beba_água.

[Boost]

Entendendo Heap e Stack no Gerenciamento de Memória

Wesley Bispo ・ Jan 3

DEV Community: Jean Grijp

Table-Driven Tests e Paralelismo

O problema dos testes repetitivos

A anatomia de um table-driven test

Subtestes com t.Run()

t.Errorf ou t.Fatalf

Execução paralela com t.Parallel()

O ciclo de vida de um teste paralelo

Controlando o paralelismo

A armadilha da variável de loop

As duas soluções

Um exemplo completo

Checklist antes de dar a suíte por concluída

go #golang #testing #tabledriventests #testesunitarios #paralelismo #concorrencia #backend #braziliandevs

6 Go Libraries That Completely Transformed Software Development in 2025

Goroutines, threads e o caos coordenado do Go Scheduler.

O que é uma Thread?

Go Scheduler

Mas o que é esse tal de P?

Chamadas bloqueantes (syscalls) e uso inteligente de threads (M)

Um pouco mais sobre stacks dinâmicas das goroutines

Como o Go lida com preempção, ou seja, como ele lida com aquelas goroutines folgadas que decidem nunca mais sair da CPU?

Limitações e armadilhas do Go Scheduler (sim, ele também tem seus dias ruins)

chegou até aqui?

Go e o Stack Invisível: Como Funções e Goroutines Administram Memória nos Bastidores.

Como o Go sabe que precisa crescer o stack?

Heap x Stack

As funções em Go

Alocação na Stack

Alocação na Heap

Consideração final

beba_água.

[Boost]

Entendendo Heap e Stack no Gerenciamento de Memória

Wesley Bispo ・ Jan 3

Subtestes com `t.Run()`

`t.Errorf` ou `t.Fatalf`

Execução paralela com `t.Parallel()`

Mas o que é esse tal de `P`?

Chamadas bloqueantes (syscalls) e uso inteligente de threads (`M`)