Falar de concorrência é entrar num daqueles temas que separam o código bonito do código que vira uma bomba-relógio. Quem já precisou lidar com _threads_ em Java ou tentou sincronizar _async/await_ em Node.js sabe: o pesadelo começa quando as tarefas resolvem brigar por recursos. A ideia é simples — fazer várias coisas ao mesmo tempo. O problema é tudo o que vem junto: race conditions, deadlocks, bloqueios, inconsistências. Um pequeno descuido e o sistema inteiro desaba. E é aí que o Go entra em cena. A linguagem nasceu com uma proposta ousada: tornar a concorrência **parte natural do código**, e não um campo minado cheio de mutexes e callbacks. Com **Goroutines e Channels**, o Go transformou um problema clássico da computação em algo… quase prazeroso de trabalhar. Neste artigo, a ideia é te mostrar — sem firulas — **por que o modelo de concorrência do Go é tão diferente**. Vamos comparar com threads e async/await, destrinchar padrões reais (como pipelines e fan-out/fan-in) e entender o que faz o Go ser tão eficiente em produção. --- ## O segredo das Goroutines Pensa nas _Goroutines como threads que tomaram café e decidiram trabalhar direito_. Enquanto uma thread tradicional pode pesar megabytes, uma Goroutine consome só alguns kilobytes — e o runtime do Go cuida de distribuir milhares delas entre as threads do sistema. Em outras palavras: você não precisa se preocupar com criação, destruição, ou sincronização manual. O Go faz isso por você, com um scheduler inteligente que roda no fundo, como um maestro regendo uma orquestra. [Artigo: De dentro do Scheduler do GO: monitorando goroutines com Prometheus e Grafana](https://iamwilliamkoller.substack.com/p/de-dentro-do-scheduler-do-go-monitorando) ```csharp Threads tradicionais: [Thread 1] -> memória alta, troca de contexto cara [Thread 2] -> bloqueios, sincronização manual Goroutines: [Goroutine 1] -> leve, multiplexada [Goroutine 2] -> leve, cooperativa ``` > a mágica está no equilíbrio — milhares de Goroutines rodando em poucas threads, com mínima sobrecarga e máxima eficiência. --- ## Channels: comunicação sem dor de cabeça Agora… concorrer é uma coisa. Comunicar é outra história. De que adianta rodar mil tarefas se elas não conseguem trocar informações sem brigar? Os **Channels** resolvem isso. Eles são como tubos seguros que ligam Goroutines — você envia e recebe dados de forma sincronizada, sem se preocupar com locks ou mutexes. ```less Goroutine A --> |channel| --> Goroutine B ``` Quando uma envia, a outra recebe. E pronto. Nenhuma corrida, nenhum caos. Essa simplicidade é o que torna o Go tão previsível. Você olha o código e entende o fluxo — sem precisar de comentários enigmáticos do tipo ``// cuidado aqui, pode dar race``. Vale também mencionar um [repositório](https://github.com/cassiobotaro/concorrencia-go) do Cássio Botaro sobre o assunto. --- ## Montando pipelines concorrentes Agora vem a parte divertida. Imagine que você tem um fluxo de dados — leitura, processamento e saída. No Go, cada uma dessas etapas pode ser uma Goroutine conectada por Channels. É o que chamamos de **pipeline concorrente**. ```go type Job struct { ID int Data string } func generator(jobs ...Job) <-chan Job { out := make(chan Job) go func() { for _, job := range jobs { out <- job } close(out) }() return out } func worker(id int, in <-chan Job, out chan<- Job) { for job := range in { job.Data += fmt.Sprintf(" [processado pelo worker %d]", id) out <- job } } func main() { jobs := generator(Job{1, "A"}, Job{2, "B"}, Job{3, "C"}) results := make(chan Job) // Fan-out: 3 workers rodando em paralelo for w := 1; w <= 3; w++ { go worker(w, jobs, results) } // Fan-in: coletando os resultados for i := 0; i < 3; i++ { fmt.Println(<-results) } } ``` O resultado? Trabalho distribuído entre várias Goroutines, cada uma fazendo sua parte. Sem bloqueios, sem drama, sem ``Thread.sleep()``. --- ## O poder do “select” Quando você precisa lidar com múltiplos canais, o Go oferece um comando que parece simples, mas é absurdamente poderoso: ``select``. Ele escuta vários canais ao mesmo tempo e reage ao primeiro que receber algo. Isso permite lidar com timeouts, cancelamentos e sinais externos sem precisar criar lógica de controle maluca. ```go select { case msg := <-dataChannel: fmt.Println("Recebido:", msg) case <-done: fmt.Println("Cancelado") case <-time.After(2 * time.Second): fmt.Println("Timeout") } ``` É o tipo de coisa que, em outras linguagens, exigiria meia dúzia de locks, timers e promessas aninhadas. Aqui, são três linhas. --- ### O duelo da concorrência: Go vs Java vs Node Imagine três programadores enfrentando o mesmo desafio: rodar **10 mil tarefas ao mesmo tempo**. Um usa **Go**, outro **Java**, e o terceiro aposta tudo no **Node.js**. Parece equilibrado… até você olhar de perto. --- **Cenário: 10k tarefas I/O bound** - Go (Goroutines): 50 MB - Java (Threads): 1.5 GB - Node.js (Async/Await): ~60 MB --- **Cenário: 10k tarefas CPU bound** - Go: 200 MB - Java: 1.8 GB - Node.js: trava o loop de eventos --- **Escalabilidade geral** - Go: Alta - Java: Média - Node.js: Limitada --- Esses números, claro, mudam conforme o contexto — mas a tendência é nítida: **Go lida melhor com volume.** Você pode lançar milhares de tarefas concorrentes e o consumo de memória continua surpreendentemente baixo. Enquanto isso, Java vai pedindo mais RAM… e o Node começa a rezar pro event loop não travar. --- ## Dicas de gente grande - **Use contextos**. Sempre que trabalhar com pipelines longos, propague context.Context. Isso evita Goroutines zumbis rodando sem necessidade. - **Controle o volume**. Mesmo sendo leves, milhares de Goroutines podem sobrecarregar I/O. Crie pools de workers. - **Monitore tudo**. Ferramentas como ``pprof`` e ``trace`` ajudam a identificar gargalos antes que virem pesadelos. - **Combine padrões**. Pipelines + fan-out/fan-in + select = código limpo, eficiente e previsível. > dominar concorrência em Go não é sobre saber comandos — é sobre **pensar em fluxo**, não em threads. --- ## Conclusão A beleza do Go está na simplicidade. As Goroutines te libertam do peso das threads, os Channels te protegem de race conditions, e o ``select`` te dá controle sobre fluxos complexos com um código que você realmente entende depois de três meses. Mais do que uma linguagem, Go é uma filosofia: **clareza antes da mágica**. E essa clareza é o que permite que times criem sistemas robustos, escaláveis e sustentáveis — sem precisar de malabarismos com concorrência. Se você trabalha com backend, dados ou sistemas distribuídos, entender Goroutines e Channels muda tudo. Você para de “gerenciar threads” e começa a **orquestrar ideias**. ### Recursos recomendados - [Documentação oficial — Goroutines](https://go.dev/doc/effective_go#goroutines) - [Documentação oficial — Channels](https://go.dev/doc/effective_go#channels) - [Tour do Go — Concurrency](https://go.dev/tour/concurrency/1) - [Go Concurrency Patterns — Rob Pike](https://talks.golang.org/2012/concurrency.slide#1) - [Artigo sobre pipelines concorrentes](https://go.dev/blog/pipelines)

Carregando...

Carregando...