DEV Community: Carolina Vila-Nova

Goroutines vs. Java Virtual Threads: um guia de sobrevivência

Carolina Vila-Nova — Sun, 22 Feb 2026 20:57:51 +0000

A evolução da concorrência em sistemas modernos atingiu um ponto de convergência muito interessante para nós, desenvolvedores de software.

De um lado, temos Go, que nasceu com uma filosofia de processos simples e leves e colocou a concorrência no centro da linguagem.

Do outro, temos Java, que com o Project Loom somado ao Spring Boot 3.2+, reinventou a infraestrutura de execução da concorrência, permitindo que o modelo imperativo pudesse ser escalável ao rodar sobre threads virtuais leves.

Antes, uma Platform Thread em Java era mapeada 1:1 para uma Thread do Sistema Operacional, a um custo altíssimo: cada thread consumia cerca de 1MB ou mais de memória apenas para existir. Ou seja, se você precisasse de 100.000 threads simultâneas, seu servidor travaria por falta de memória (OOM).

Java passou 20 anos tentando resolver isso com Reactive Programming (WebFlux), mas o preço foi abandonar o estilo imperativo e adotar um estilo declarativo/funcional complexo.

Com as virtual threads, ela retornou ao modelo imperativo de código sequencial (fazerA(), depois fazerB(); fácil de ler e debugar) e mudou a implementação da concorrência, tornando-a tão eficiente quanto as goroutines. Mas com uma grande sacada: a retrocompatibilidade.

Vale ressaltar que as Virtual Threads consomem apenas alguns KB, assim como as goroutines.

Para ilustrar melhor essa comparação, vamos nos inspirar em "Fallout" e utilizar o sistema de monitoramento da Vault-Tec: um Pip-Boy (emissor) enviando dados de radiação para um Terminal de Vault (receptor).

Canais e controle explícito em Go

Go não tenta esconder que você está lidando com processos paralelos; ela apenas torna isso indolor através do modelo CSP (Communicating Sequential Processes). A filosofia é: "Não comunique compartilhando memória; compartilhe memória comunicando".

O desenvolvedor detém o controle do ciclo de vida da goroutine ao chamar go func(). Canais (chan) são a forma padrão de comunicação, um cidadão de primeira classe. A conexão entre os canais e a sincronização também se dão explicitamente.

O tratamento de erro é onipresente: ele faz parte do fluxo de controle. Se um canal fecha ou uma leitura falha, você decide exatamente o que fazer no próximo passo. Para garantir que o terminal não feche antes de o Pip-Boy terminar, você pode usar o sync.WaitGroup ou simplesmente o fechamento do canal como sinalizador para o loop range.

No exemplo abaixo, criamos um retry em caso de erro, mas caso as falhas ultrapassem determinado percentual, o processo é abortado.

const terminalErrorMsg = "❌ [Terminal] Erro fatal de hardware"
func VaultMonitor() {
    // Canal de dados para comunicação entre o Pip-Boy e o Terminal
    dataStream := make(chan string)

    // Goroutine do Pip-Boy (Emissor)
    go func() {
        defer close(dataStream)
        for i := 0; i < 10; i++ {
            msg, err := lerSensorPipBoy()

            if err != nil {
                // Tratamento de erro explícito com log estruturado
                slog.Warn("⚠️ [Pip-Boy] Falha na leitura", "erro", err)
                time.Sleep(500 * time.Millisecond)
                continue
            }

            slog.Info("📱 [Pip-Boy] Sinal enviado")
            dataStream <- msg
            time.Sleep(time.Second)
        }
    }()

    // Loop principal (Receptor/Terminal)
    for msg := range dataStream {
        err := processarNoTerminal(msg)
        if err != nil {
            slog.Error(terminalErrorMsg, "erro", err)
            return
        }
        slog.Info("🖥️ [Terminal Log]", "status", msg)
    }

    slog.Info("✅ Monitoramento finalizado com sucesso.")
}

func lerSensorPipBoy() (string, error) {
    // Simula 20% de chance de erro de leitura
    if rand.Float32() < 0.2 {
        return "", errors.New("sensor obstruído por poeira atômica")
    }
    slog.Error(terminalErrorMsg, "erro", errors.New("sensor obstruído por poeira atômica"))
    return fmt.Sprintf("%d RADs", rand.Intn(100)), nil
}

func processarNoTerminal(msg string) error {
    // Simula uma falha rara no hardware do terminal
    if rand.Float32() < 0.05 {
        return errors.New("curto-circuito no painel principal")
    }
    slog.Error(terminalErrorMsg, "erro", errors.New("curto-circuito no painel principal"))
    return nil
}

Infraestrutura e abstração em Java

Em vez de criar novos tipos primitivos (como chan), os arquitetos do Project Loom modificaram a JVM para que as estruturas tradicionais de bloqueio (Thread.sleep(), BlockingQueue.take()) e de concorrência (ConcurrentHashMap, AtomicInteger) passassem a ser 'amigáveis' às Virtual Threads.

A diferença é que o bloqueio agora é não-bloqueante para o SO: enquanto o fluxo do código espera de forma sequencial, a thread real do SO é liberada para outras tarefas. A sinalização de término, por sua vez, segue o padrão Java, sendo feita via mensagens "sentinela" ou interrupção de thread.

No lugar de um controle manual de threads, o Spring Boot aplica a Inversão de Controle para gerenciar o paralelismo. Você apenas anota o método que precisa ser assíncrono, e o framework se encarrega de instanciar e escalar as Virtual Threads nos bastidores.

O StructuredTaskScope (Concorrência Estruturada) funciona como os grupos de Go. A diferença é que o Java trata o grupo de threads como uma unidade de trabalho hierárquica: se a tarefa principal (o Overseer) morre, todas as sub-tarefas (os moradores) são canceladas automaticamente. É uma forma de evitar "goroutines leaks".

Enquanto em Go o context.Context é repassado manualmente, no Spring, o contexto é propagado automaticamente através de ThreadLocal (que foi otimizado para Virtual Threads).

Em Java/Spring, o erro geralmente interrompe o fluxo atual e é capturado. O controle é menos uma questão de "o que fazer a cada linha" e mais de "como recuperar o estado da aplicação".

O tratamento de erro em threads assíncronas é centralizado via interceptadores ou blocos try-catch tradicionais. O Spring Boot oferece o AsyncUncaughtExceptionHandler para capturar erros que ocorrem em métodos @Async sem que você precise poluir a lógica.

@Slf4j
@Service
public class VaultCommunicationService {

    private final BlockingQueue<String> dataStream = new LinkedBlockingQueue<>(10);

    @Async
    public void pipBoySender() {
        try {
            while (!Thread.currentThread().isInterrupted()) {
                String msg = "☢️ Nível de Radiação: " + new Random().nextInt(100) + " RADs";
                dataStream.put(msg); 
                log.info("📱 [Pip-Boy] Sinal enviado para a fila.");
                Thread.sleep(1000); 
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            log.error("🚨 Conexão com Pip-Boy interrompida!");
        } catch (Exception e) {
            log.error("❌ Erro no sensor: {}", e.getMessage());
        }
    }

    @Async
    public void terminalReceiver() {
        try {
            while (true) {
                String msg = dataStream.take(); 
                log.info("🖥️ [Terminal Log]: {}", msg);
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

Diferenças em compilação e escalonamento

Ao compilar-se um programa em Go, o compilador não traduz apenas o código, mas injeta um Runtime dentro do executável, incluindo aí o Scheduler (escalonador). Esse escalonador usa o modelo M:P:N: distribui "M" Goroutines em "P" contextos de processadores lógicos, que rodam sobre "N" threads do sistema operacional.

O Runtime é prioritariamente cooperativo, mas possui mecanismos de preempção para evitar que uma única goroutine "sequestre" o processador em loops intensos. Se uma Goroutine é bloqueada, ele a retira de cena e coloca outra no lugar imediatamente, sem interferência do SO. É um controle total dentro do processo.

A Java Virtual Machine (JVM) atua como uma camada intermediária entre o código (o arquivo .jar) e o hardware. A partir do Project Loom, as Virtual Threads são gerenciadas por um componente da JVM chamado ForkJoinPool, que atua como escalonador padrão.

Ele mantém um pool de threads reais do SO, as chamadas Carrier Threads. Quando você inicia uma Virtual Thread, a JVM a "monta" em uma dessas threads reais para execução. Ao deparar com um ponto de bloqueio (como dataStream.take()), a JVM captura o estado atual da Virtual Thread (o stack) e o move para a memória (Heap). A thread real do SO fica livre para "transportar" outra Virtual Thread. Quando o dado chega, a JVM "remonta" o estado e continua a execução. Este processo recebe o nome de Continuation.

Essa distinção explica por que o Java 21+ é uma mudança tão significativa: ele não mudou apenas a biblioteca de Threads, mas sim a forma como a JVM conversa com o processador para permitir que o código imperativo tradicional tenha a performance de um sistema de alta concorrência.

Uma vantagem é que as Virtual Threads são compatíveis com milhões de linhas de código legado, bastando para isso a habilitação de uma chave no application.yml (a configuração spring.threads.virtual.enabledem Java 21 e Spring Boot 3.2+).

Conclusão

A convergência entre Go e Java 21+ na questão da concorrência é uma vitória para os desenvolvedores. Seja qual linguagem atenda melhor suas necessidades de projeto, o objetivo será o mesmo: garantir que o seu sistema sobreviva ao "apocalipse" de tráfego das aplicações modernas. A Wasteland nunca foi tão amigável para quem precisa de performance.

Referências

Gerenciamento seguro e eficiente de tokens com Go e Redis

Carolina Vila-Nova — Wed, 12 Nov 2025 02:56:34 +0000

Publicado originalmente no Medium

Carolina Vila-Nova

Em um cenário de microsserviços e APIs expostas, o gerenciamento seguro e eficiente de tokens de autenticação é crucial para garantir a integridade e o desempenho do sistema.

Recentemente, tive a oportunidade de trabalhar na implementação de uma abordagem que combina cache com refresh automático de tokens, tirando proveito do ecossistema robusto do Go e da alta performance do Redis.

A seguir, detalho essa solução, explorando os desafios iniciais, as estratégias de design e os benefícios alcançados.

Nosso ponto de partida foi a necessidade de autenticação junto a uma API externa para poder gerar — no ambiente desse cliente mas em situações específicas definidas por nossa regra de negócio — mensagens informativas aos usuários.

Uma questão que logo se impôs foi onde armazenar o token obtido, levando em consideração o alto volume de tráfego na nossa API. Armazená-lo diretamente em uma instância do serviço não era uma opção viável, pois colocaria em risco a segurança e a escalabilidade do sistema.

A ideia central foi armazenar o token em um cache distribuído, com um tempo de vida (TTL) equivalente ao tempo de validade do próprio token. Algumas características fizeram com que a escolha do Redis como sistema de cache para esse caso de uso não fosse aleatória, entre elas:

Desempenho: com armazenamento em memória, o Redis oferece tempos de resposta extremamente rápidos, da ordem de milissegundos. Isso é essencial quando se precisa acessar e validar o token de forma rápida em cada requisição. Um cache lento impactaria diretamente a performance da aplicação.
Suporte nativo a TTL: o Redis se encarrega de expirar o token automaticamente após o tempo definido, garantindo que ele seja renovado antes de expirar e prevenindo erros de autenticação. Essa funcionalidade integrada simplifica a lógica de refresh e garante sua confiabilidade.
Atomicidade: as operações acontecem como um todo ou não acontecem, garantindo a consistência dos dados no cache. Isso é importante no contexto do cache de tokens para evitar condições de corrida quando múltiplas instâncias do serviço tentam acessar ou atualizar o token simultaneamente.
Escalabilidade horizontal: o suporte ao clustering permite escalar horizontalmente a capacidade do cache conforme a demanda aumenta sem comprometer a performance e evitando gargalos

A solução

Antes de realizar qualquer requisição à API protegida, a função verifica se existe um token válido no cache.

func GetToken(key string) (string, error) {  
 cacheToken, err := cache.Get(key)  
 if err != nil {  
  return "", err  
 }  
 return cacheToken, nil  
}

O sistema checa também se esse token ainda é válido, considerando uma margem de segurança (um “buffer”) para evitar requisições com tokens prestes a expirar.

Bibliotecas como a github.com/golang-jwt/jwt/v5 nos permitem decodificar o JWT de forma segura a partir de suas Claims e verificar a data de expiração.

import (  
    "time"  
    "github.com/golang-jwt/jwt/v5"  
)  

func ExpiredToken(tokenString string, buffer time.Duration) (bool, error) {  
    token, _, err := new(jwt.Parser).ParseUnverified(tokenString, jwt.MapClaims{})  
    if err != nil {  
        return true, err // Considera expirado em caso de erro na leitura  
    }  

    claims, ok := token.Claims.(jwt.MapClaims)  
    if !ok {  
        return true, err  // Considera expirado se não conseguir extrair claims  
    }  

    exp, ok := claims["exp"].(float64)  
    if !ok {  
       return true, err // Considera expirado se "exp" não estiver presente  
    }  

    expirationTime := time.Unix(int64(exp), 0)  
 return time.Now().Add(buffer).After(expirationTime), nil  
}  

//Nota: essa biblioteca oferece mais opções de validação. Nesta implementação,  
// usamos ParseUnverified apenas para extrair a data de expiração.   
//O token é validado de fato pela API de autenticação

Caso o token não seja encontrado no cache ou tenha expirado (dentro do "buffer" de segurança), o sistema solicita um novo token à API de autenticação e o armazena no cache com o TTL apropriado.

Pode-se ainda usar a biblioteca crypto/rand do Go para gerar um ID único para cada token (um "nonce"), aumentando a segurança e rastreabilidade.

func GetNewToken() (string, error) {  
 // Lógica para obter novo token da API de autenticação  
 // ...  
 return "newToken", nil  
}  

func StoreTokenCache(key string, token string, ttl time.Duration) error {  
 err := cache.Set(key, token, ttl)  
 if err != nil {  
  return err  
 }  
 return nil  
}

O TTL do cache garante que o token seja automaticamente atualizado antes de expirar, evitando a necessidade de tentativas repetidas ("retries") em caso de falha na autenticação. A margem de segurança garante que o token seja renovado antes mesmo de expirar, prevenindo erros. Goroutines são utilizadas para realizar o refresh de forma assíncrona, sem bloquear o fluxo principal da aplicação.

func stageRefresh(key string, timeToRefresg time.Duration) {  
 go func() { // Cria uma goroutine para o refresh  
  time.Sleep(timeToRefresh) // espera o tempo determinado  

  newToken, err := GetNewToken()  
  if err != nil {  
   fmt.Println("Failed to renew token:", err)  
   return  
  }  

  err = StoreTokenCache(key, newToken, tokenTtl)  
  if err != nil {  
   fmt.Println("Failed to store new token in cache:", err)  
   return  
  }  

  fmt.Println("Token refreshed")  
 }()  
}  

// Chamada quando o token é gerado/obtido pela primeira vez  
stageRefresh(tokenKey, timeToRefresh)

Benefícios da abordagem adotada

Segurança: O token não fica armazenado localmente por tempo indeterminado, reduzindo a janela de oportunidade para ataques.
Escalabilidade: O cache distribuído permite que múltiplas instâncias do serviço compartilhem o mesmo token, eliminando a necessidade de autenticações redundantes.
Resiliência: O refresh automático garante que o token esteja sempre disponível, minimizando interrupções no serviço.
Performance: Evita retries, otimizando o tempo de resposta das requisições.

Em resumo, o uso do cache com refresh automático nos permitiu criar uma solução robusta, segura e escalável para o gerenciamento de tokens, garantindo a disponibilidade e a integridade do serviço.

Fontes

github.com/go-redis/redis/v8: Para interagir com o Redis e armazenar e/ou invalidar os tokens de maneira eficiente

github.com/golang-jwt/jwt/v5: Para manipulação de tokens JWT, incluindo decodificação, validação e, opcionalmente, geração (embora a geração do token seja tipicamente feita pelo servidor de autenticação)

Concorrência em Go: o uso de locks e channels para evitar deadlocks

Carolina Vila-Nova — Wed, 12 Nov 2025 02:49:16 +0000

Publicado originalmente no [Medium]

Carolina Vila-Nova
A concorrência é um dos superpoderes do Go, mas também pode se tornar uma dor de cabeça para o desenvolvedor iniciante. Felizmente, Go nos dá múltiplas ferramentas nativas para lidar com código concorrente –a questão é saber quando usar cada uma delas. Este artigo aborda esse tema, usando exemplos com diferentes complexidades.

Sincronização para quê?

Imagine que você está construindo um contador de visitantes para um site.

type VisitorCounter struct {  
    count int  
}  

func (c *VisitorCounter) Increment() {  
    c.count++    
}  

func (c *VisitorCounter) GetCount() int {  
    return c.count    
}

À primeira vista, o código parece correto. Mas quando N goroutines são executadas simultaneamente (e de maneira randômica), algo estranho acontece:

// Duas requisições HTTP chegam simultaneamente  
// Goroutine A (Usuário 1):           Goroutine B (Usuário 2):  
lê c.count (valor atual: 100)       lê c.count (valor atual: 100)  
incrementa para 101                  incrementa para 101    
escreve 101 em c.count              escreve 101 em c.count  

// Resultado: count = 101 (deveria ser 102)  
// Um visitante foi "perdido"

É o que se chama de “race condition”, ou condição de corrida: como as threads acessam um recurso compartilhado mas não estão sincronizadas, o resultado final depende de qual é executada primeiro. Em um site com milhares de visitantes simultâneos, você poderia perder uma quantidade significativa de dados. Fca clara assim a necessidade de sincronizar o acesso a dados compartilhados.

Usando mutexes

Uma possível solução é usar a primitiva de sincronização mutex (acrônimo de "mutual exclusion") para garantir que apenas uma goroutine possa modificar o contador por vez:

type SafeVisitorCounter struct {  
    mu    sync.Mutex  
    count int  
}  

func (c *SafeVisitorCounter) Increment() {  
    c.mu.Lock()  
    defer c.mu.Unlock()  
    c.count++  // Apenas uma goroutine executa isso por vez  
}  

func (c *SafeVisitorCounter) GetCount() int {  
    c.mu.Lock()  
    defer c.mu.Unlock()  
    return c.count  // Leitura também precisa ser protegida  
}

Agora você tem um contador mais seguro — mas também um problema de performance. Se seu site tem um dashboard que exibe o contador em tempo real e 1.000 usuários querem visualizá-lo simultaneamente, todos vão ter que esperar em fila para ler o valor, mesmo que não exista conflito entre as leituras.

Otimizando leituras com RWMutex

É aí que podemos empregar um mutex que possa distinguir entre operações de leitura e de escrita:

type OptimizedVisitorCounter struct {  
    mu    sync.RWMutex    
    count int  
}  

func (c *OptimizedVisitorCounter) Increment() {  
    c.mu.Lock()         // Escrita ainda precisa de acesso exclusivo  
    defer c.mu.Unlock()  
    c.count++  
}  

func (c *OptimizedVisitorCounter) GetCount() int {  
    c.mu.RLock()        // Múltiplas leituras podem acontecer simultaneamente  
    defer c.mu.RUnlock()  
    return c.count  
}

Com essa mudança, N usuários podem ler o contador simultaneamente, enquanto apenas as escritas (incrementos) precisam esperar por acesso exclusivo. Assim, a performance melhora para workloads com muitas leituras.

Um exemplo mais complexo: gerenciamento de tokens

Agora que entendemos os conceitos básicos, vamos aplicá-los a um problema mais realista. Vamos construir um microsserviço que precisa se autenticar junto a uma API externa usando tokens JWT. Esses tokens expiram periodicamente e precisam ser renovados, mas você não quer ter que fazer uma nova chamada à API a cada requisição.


func (s *TokenService) GetToken(ctx context.Context) (string, error) {  
    s.mu.RLock()  
    if time.Now().Before(s.expiresAt) && s.token != "" {  
        token := s.token  
        s.mu.RUnlock()  
        return token, nil  
    }  
    s.mu.RUnlock()  

    s.mu.Lock()  
    defer s.mu.Unlock()  

    newToken, expiresAt, err := s.apiClient.GetNewToken(ctx)  
    if err != nil {  
        return "", err  
    }  

    s.token = newToken  
    s.expiresAt = expiresAt  
    return newToken, nil  
}

Aqui há pequeno problema. Se 50 requisições chegarem simultaneamente quando o token está expirando, todas vão tentar renová-lo, resultando em 50 chamadas desnecessárias à API externa.

O padrão "double-check"

Uma solução elegante para esse problema é o padrão “double-check”, ou seja, uma dupla checagem da condição, uma vez com o read lock e outra vez com o write lock.


func (s *SimpleTokenService) GetToken() string {  
 // primeira checagem - leitura rápida  
 s.mu.RLock()  
 if time.Now().Before(s.expiry) && s.token != "" {  
  token := s.token  
  s.mu.RUnlock()  
  return token   
 }  
 s.mu.RUnlock()  

 // segunda checagem com write lock  
 s.mu.Lock()  
 defer s.mu.Unlock()  

 // Verifica se outra goroutine já obteve o token atualizado  
 if time.Now().Before(s.expiry) && s.token != "" {  
  return s.token   
 }  

 // Apenas uma goroutine chega até aqui  
 fmt.Println("🔄 Making API call...")  
 time.Sleep(100 * time.Millisecond)   

 s.token = fmt.Sprintf("token-%d", time.Now().Unix())  
 s.expiry = time.Now().Add(5 * time.Second)  
 return s.token  
}

O double-check previne o problema do “thundering herd”, que ocorre quando várias threads competem por um recurso limitado assim que ele se torna disponível. Em vez de cada uma fazer uma chamada à API, elas compartilham o resultado de apenas uma chamada.

Quando as coisas dão errado: "deadlocks"

Quando nossa aplicação se torna mais complexa e múltiplos recursos são compartilhados entre vários processos, surge o risco de deadlock. Situações comuns em que isso ocorre são acessos a dispositivos ou a execução de transações em bases de dados.

Considere um sistema de transferência bancária:

type Account struct {  
    id      int  
    mu      sync.Mutex  
    balance float64  
}  

func Transfer(from, to *Account, amount float64) error {  
    from.mu.Lock()  
    defer from.mu.Unlock()  

    to.mu.Lock()    
    defer to.mu.Unlock()  

    if from.balance < amount {  
        return errors.New("saldo insuficiente")  
    }  

    from.balance -= amount  
    to.balance += amount  
    return nil  
}

Mas veja o que ocorre quando duas transferências simultâneas acontecem em direções opostas:

// Goroutine 1: Transfer(contaA, contaB, 100)  
contaA.mu.Lock() // ✅ Consegue lock A  
contaB.mu.Lock() // ⏳ Espera Goroutine 2 liberar B  
// Goroutine 2: Transfer(contaB, contaA, 200)  
contaB.mu.Lock() // ✅ Consegue lock B  
contaA.mu.Lock() // ⏳ Espera Goroutine 1 liberar A  
// Resultado: Ambas esperam para sempre

Os dois processos ficam em estado de espera mútua indefinida, cada um bloqueando um recurso que o outro precisa e que só pode ser libertado pelo processo bloqueado, impedindo a execução de ambos e, potencialmente, do sistema.

Uma possível solução seria estabelecer uma ordem consistente para a aquisição de locks:

func SafeTransfer(from, to *Account, amount float64) error {  
    first, second := from, to  
    if first.id > second.id {  
        first, second = second, first  
    }  

    first.mu.Lock()  
    defer first.mu.Unlock()  

    second.mu.Lock()  
    defer second.mu.Unlock()  

    if from.balance < amount {  
        return errors.New("saldo insuficiente")  
    }  

    from.balance -= amount  
    to.balance += amount  
    return nil  
}

Agora, independentemente da direção da transferência, os locks são sempre adquiridos na mesma ordem, eliminando a possibilidade de deadlock ou de race condition.

Quando usar channels

Quando não há estado compartilhado a ser protegido, mas há a necessidade de garantir uma ordem de processamento, uma coordenação de comportamentos ou estados a comunicar, o Go oferece uma ferramenta distinta: channels.

No caso a seguir, queremos processar uploads de imagens em um pipeline:

func ProcessImageUploads(imagePaths []string) []ProcessedImage {  
    rawImages := make(chan string, 10)  
    resizedImages := make(chan ResizedImage, 10)  
    finalImages := make(chan ProcessedImage, 10)  

    go func() {  
        defer close(rawImages)  
        for _, path := range imagePaths {  
            rawImages <- path  // "Aqui está uma imagem para processar"  
        }  
    }()  

    go func() {  
        defer close(resizedImages)  
        for path := range rawImages {  
            img := loadImage(path)  
            resized := resize(img)  
            resizedImages <- resized  // "Aqui está uma imagem redimensionada"  
        }  
    }()  

    go func() {  
        defer close(finalImages)  
        for resized := range resizedImages {  
            final := applyFilters(resized)  
            finalImages <- final  // "Aqui está uma imagem processada"  
        }  
    }()  

    var results []ProcessedImage  
    for final := range finalImages {  
        results = append(results, final)  
    }  

    return results  
}

Aqui, o uso de channels garante que as imagens sejam processas em um pipeline em que os estágios correm de maneira concorrente para melhor performance e cada um processa as imagens conforme elas são disponibilizadas.

Combinando ambas as abordagens

Em sistemas reais, frequentemente precisamos fazer uso de ambas as abordagens. Considere um sistema de métricas que coleta dados de múltiplas fontes:

type MetricsCollector struct {  
    // Channel para coordenação - receber eventos  
    events chan MetricEvent  

    // Lock para proteção - guardar métricas agregadas  
    mu      sync.RWMutex  
    metrics map[string]float64  
}  

func (m *MetricsCollector) Start() {  
    go func() {  
        for event := range m.events {  // Channel: coordenação  
            m.mu.Lock()                // Lock: proteção de dados  
            m.metrics[event.Name] += event.Value  
            m.mu.Unlock()  
        }  
    }()  
}  

func (m *MetricsCollector) RecordEvent(name string, value float64) {  
    m.events <- MetricEvent{Name: name, Value: value}  // Channel: comunicação  
}  

func (m *MetricsCollector) GetMetric(name string) float64 {  
    m.mu.RLock()     // Lock: leitura segura  
    defer m.mu.RUnlock()  
    return m.metrics[name]  
}

Aqui usamos channels para coordenar o envio de eventos (comportamento) e locks para proteger o map de métricas (dados).

Framework de decisão

Use mutex quando:

Você tem dados compartilhados (variáveis, maps, slices)
Múltiplas goroutines precisam ler/escrever os mesmos dados
Você quer simplicidade e performance para proteção de estado

Use RWMutex quando:

Você tem muito mais leituras que escritas
A performance de leituras concorrentes é importante
Você ainda está protegendo dados compartilhados

Use channels quando:

Você quer coordenar o comportamento entre goroutines
Você está implementando pipelines ou worker pools
Você quer comunicar valores, não proteger estado compartilhado

Use ambos quando:

Você tem um sistema complexo com coordenação E proteção de dados
Você quer separar claramente a comunicação da proteção de estado

Lembre-se dessa máxima do Go:

“Don’t communicate by sharing memory; share memory by communicating.”

Conclusão

A chave para um código Go concorrente robusto é escolher a ferramenta certa para cada problema específico, entender as compensações e sempre pensar em cenários de falha.

PS — O Go tem uma ferramenta marota para detectar deadlocks: a flag -race

go run -race main.go