DEV Community: Fabio Rocha

🧵 ThreadLocal no Java 21 – o que mudou, o que continua e quando você deve (ou não) usar

Fabio Rocha — Wed, 29 Jul 2026 23:04:16 +0000

E aí, dev que já passou horas debugando um ThreadLocal que não foi limpo e vazou memória? Pois é. Esse velho conhecido do Java 1.2 sempre foi a solução para guardar dados "por thread" como o userId de uma requisição, ou uma conexão de banco que não pode ser compartilhada.

Mas aí chegaram as Virtual Threads no JDK 21, e o jogo mudou. Criar milhões de threads leves virou realidade, e o bom e velho ThreadLocal começou a mostrar suas fraquezas. A boa notícia? O Java 21 trouxe uma alternativa moderna e elegante: Scoped Values.

Vamos entender tudo isso com exemplos práticos. Bora? 🚀

🔍 O que é ThreadLocal (e por que você usava isso)?

ThreadLocal é uma classe que permite criar variáveis que só podem ser acessadas e modificadas pela mesma thread. Cada thread que acessa um ThreadLocal tem sua própria cópia independente da variável.

Exemplo clássico:

public class ContextoUsuario {
    private static final ThreadLocal<String> USER_ID = new ThreadLocal<>();

    public static void setUserId(String userId) {
        USER_ID.set(userId);
    }

    public static String getUserId() {
        return USER_ID.get();
    }

    public static void clear() {
        USER_ID.remove(); // 👈 NUNCA ESQUEÇA DISSO!
    }
}

// Em algum lugar do código...
ContextoUsuario.setUserId("alice123");
String user = ContextoUsuario.getUserId(); // "alice123"
ContextoUsuario.clear();

Use quando: precisar associar dados a uma thread específica sem passar parâmetros por toda a cadeia de chamadas tipo userId numa requisição web, conexão de banco, ou transação.

⚠️ Os problemas clássicos do ThreadLocal (que todo mundo já sofreu)

1. 💀 Memory Leak

Se você esquecer de chamar remove(), o valor fica preso na thread. Se a thread for reaproveitada (como num pool), o valor vaza e pode nunca ser coletado.

2. 🔄 Contaminação entre requisições

Num pool de threads, uma requisição pode "herdar" o ThreadLocal da requisição anterior, porque a thread foi reaproveitada. Resultado: usuário A vê dados do usuário B. Um pesadelo de segurança.

3. 🧪 Dificuldade de testar

O comportamento do ThreadLocal depende do contexto de execução da thread, o que torna os testes imprevisíveis e difíceis de controlar.

4. 🌍 Global state disfarçado

Embora sejam "locais à thread", múltiplas threads compartilham o mesmo código. O uso excessivo cria dependências escondidas que tornam o código difícil de entender.

🧵 O problema com Virtual Threads

Aqui a coisa fica séria.

Virtual threads são leves e descartáveis você pode criar milhões delas. Elas aparecem e desaparecem em frações de milissegundo.

O ThreadLocal, por sua vez, foi feito para threads longas e reutilizáveis. Com virtual threads, cada uma pode ter seu próprio ThreadLocal e, se você estiver armazenando objetos grandes, o heap pode explodir com milhões de cópias.

Além disso, se a virtual thread terminar e o ThreadLocal não for limpo, o valor pode continuar ocupando memória mesmo depois que a thread já morreu.

⚠️ Importante: Nas versões preview do JDK 19 e 20, era possível criar virtual threads sem suporte a ThreadLocal. No JDK 21, todas as virtual threads suportam ThreadLocal para garantir compatibilidade com bibliotecas existentes. Mas isso não significa que você deva usar significa que você precisa ter mais cuidado ainda.

✨ A novidade do Java 21: Scoped Values

O Java 21 trouxe os Scoped Values (JEP 446). A ideia é simples e elegante:

Em vez de guardar dados dentro da thread (como o ThreadLocal), o ScopedValue prende o valor a um bloco de código.
Quando o bloco termina, o valor some automaticamente sem remove(), sem memory leak.
É imutável: uma vez bindado, não pode ser alterado.
Funciona perfeitamente com virtual threads.

Exemplo com ScopedValue:

public class ContextoModerno {
    // Declara o ScopedValue (geralmente static final)
    private static final ScopedValue<String> USER_ID = ScopedValue.newInstance();

    public void processarRequisicao(String userId) {
        // "Amarra" o valor a um bloco de código
        ScopedValue.where(USER_ID, userId).run(() -> {
            // Dentro deste bloco, USER_ID.get() retorna "userId"
            System.out.println("Usuário: " + USER_ID.get());
            chamarOutroMetodo(); // O valor continua disponível
        });
        // Fora do bloco, USER_ID.get() lança exceção
    }

    private void chamarOutroMetodo() {
        // Ainda consegue acessar o valor aqui dentro
        String user = USER_ID.get();
        System.out.println("Método aninhado: " + user);
    }
}

O que acontece aqui?

O valor userId fica disponível apenas dentro do bloco run() e em todos os métodos chamados a partir dele.
Quando o bloco termina, o valor é automaticamente descartado.
Nada de remove() o Java cuida de tudo.

📊 Comparativo rápido

Característica	ThreadLocal	ScopedValue (Java 21)
Quando surgiu	Java 1.2	Java 21
Onde os dados ficam	Dentro da thread (`ThreadLocalMap`)	Vinculados ao bloco de código (stack)
Limpeza	Manual (`remove()`)	Automática ao sair do bloco
Imutável	❌ Pode ser alterado	✅ Imutável após bind
Virtual threads	Funciona, mas com risco de memory leak	Projetado para virtual threads
Performance	Busca em hashtable por thread	Mais eficiente em cenários de curta duração
Risco	Memory leak, contaminação entre threads	Mínimo

🧭 Quando usar cada um?

✅ Use ThreadLocal se:

Você está mantendo código legado que já usa ThreadLocal
Precisa de um valor que realmente deve viver durante toda a vida da thread (ex: pool de conexões JDBC)
Não está usando virtual threads (ou está usando platform threads tradicionais)

✅ Use ScopedValue se:

Está no Java 21 ou superior
Usa virtual threads (ou planeja usar)
Precisa passar contexto (ex: userId, transactionId, tenantId) por uma cadeia de chamadas
Quer código mais seguro, limpo e sem memory leak

❌ Evite ThreadLocal se:

Está usando virtual threads e armazenando objetos grandes
Não quer se preocupar com remove() e memory leak
Quer código mais fácil de testar e entender

💡 Dica de ouro

Se você está no Java 21 e usando virtual threads, ScopedValue é o caminho. ThreadLocal ainda funciona, mas você vai pagar o preço em memória e complexidade.

E lembre-se: se for usar ThreadLocal em qualquer cenário, sempre envolva o uso com try-finally e chame remove() no finally. É feio, mas é necessário.

🎯 Conclusão

O ThreadLocal serviu bem por décadas, mas o mundo mudou. As virtual threads vieram para ficar, e com elas veio a necessidade de ferramentas mais modernas e seguras.

O ScopedValue não é só "um ThreadLocal melhor" é uma mudança de paradigma: dados atrelados a blocos de código, não a threads. Mais seguro, mais performático, mais fácil de raciocinar.

Da próxima vez que for guardar um userId ou um contexto de requisição, pergunte-se: estou no Java 21? Se sim, dê uma chance ao ScopedValue. Sua memória (e seu eu do futuro debugando) vão agradecer. 🧵✨

Já usou ScopedValue? Ou ainda sofre com ThreadLocal? Conta aí nos comentários! 👇

Java21 #VirtualThreads #ThreadLocal #ScopedValue #Concorrência

Quer mais? No próximo post vou mostrar como migrar um código real de ThreadLocal para ScopedValue num projeto Spring Boot. Até lá! 🚀

"Sistemas não transacionais? Sim, dá pra ter consistência (sem surtar)" – O guia do Saga Pattern, Outbox e idempotência

Fabio Rocha — Thu, 23 Jul 2026 01:44:50 +0000

🧠 O problema clássico: você não está mais no seu banco relacional

Lembra daquela época boa em que você dava um @Transactional e tudo era feliz? Commit ou rollback, nunca meio termo. Aí o mundo resolveu ir pra microsserviços, bancos NoSQL, filas, eventos… e essa rigidez ACID foi pro espaço.

O que fazer quando você precisa garantir que várias operações distribuídas aconteçam de forma consistente sem ter um banco que coordene isso tudo?

A resposta vem em quatro letras: BASE (Basic Availability, Soft state, Eventual consistency). E na prática, isso se traduz em:

Saga Pattern (coreografia ou orquestração)
Compensação (o tal do rollback manual)
Idempotência (pra não repetir bagunça)
Transactional Outbox (pra não perder mensagens)
Tabela de estado/log (pra saber onde cada saga está)

Vamos destrinchar cada um com exemplos de código (simulando um sistema de e-commerce bem safado).

1️⃣ Saga Pattern – quebre a transação grande em pedaços pequenos

A ideia é linda: em vez de tentar fazer um COMMIT gigante que abrace vários serviços, você divide a operação em pequenas transações locais, cada uma com sua própria ação e sua ação de compensação (caso algo dê errado).

Existem dois jeitos de orquestrar uma saga:

🎭 Coreografia (cada serviço faz sua parte e emite eventos)

Ninguém centraliza o fluxo. Cada serviço escuta eventos e reage.

// Serviço de Pedidos
public void criarPedido(PedidoCommand cmd) {
    pedidoRepo.save(cmd);  // transação local
    eventBus.publish(new PedidoCriadoEvent(cmd.getId(), cmd.getClienteId()));
}

// Serviço de Pagamentos (escuta PedidoCriadoEvent)
@EventListener
public void processarPagamento(PedidoCriadoEvent event) {
    try {
        pagamentoService.autorizar(event.getClienteId(), event.getValor());
        eventBus.publish(new PagamentoAutorizadoEvent(event.getPedidoId()));
    } catch (Exception e) {
        eventBus.publish(new PagamentoFalhouEvent(event.getPedidoId()));
    }
}

// Serviço de Estoque (escuta PagamentoAutorizadoEvent)
@EventListener
public void reservarEstoque(PagamentoAutorizadoEvent event) {
    // reserva produtos...
}

Vantagem: baixo acoplamento, cada serviço só conhece seus eventos.

Desvantagem: fluxo fica implícito, difícil de monitorar.

🎼 Orquestração (um serviço central manda em tudo)

Aqui o "maestro" dita cada passo e sabe o que fazer em caso de falha.

public class PedidoOrquestrador {

    public void executarSaga(PedidoCommand cmd) {
        try {
            // Passo 1: Criar pedido
            String pedidoId = pedidoClient.criar(cmd);

            // Passo 2: Processar pagamento
            String pagamentoId = pagamentoClient.autorizar(cmd.getClienteId(), cmd.getValor());

            // Passo 3: Reservar estoque
            estoqueClient.reservar(cmd.getItens());

            // Passo 4: Finalizar
            pedidoClient.confirmar(pedidoId);

        } catch (PagamentoException e) {
            // Compensação do passo 1
            pedidoClient.cancelar(pedidoId);
            throw new SagaException("Pagamento falhou, pedido cancelado");
        } catch (EstoqueException e) {
            // Compensação do passo 1 e 2
            pedidoClient.cancelar(pedidoId);
            pagamentoClient.estornar(pagamentoId);
            throw new SagaException("Estoque insuficiente");
        }
    }
}

Vantagem: fluxo explícito, fácil de logar e monitorar.

Desvantagem: orquestrador vira ponto de acoplamento.

✅ Recomendação: comece com orquestração quando o fluxo for complexo e você precisar de visibilidade. Use coreografia quando cada serviço for realmente independente.

2️⃣ Mecanismo de Compensação – o seu rollback manual

Em sistemas não transacionais, não existe ROLLBACK. Se a etapa 2 falhou, você precisa executar uma ação reversa da etapa 1. É o famoso "desfazer".

Exemplo de compensação em um serviço de reserva de hotéis:

public class ReservaService {

    @Transactional
    public String criarReserva(ReservaRequest req) {
        // ação principal
        reservaRepo.save(new Reserva(req.getId(), req.getQuarto(), "CONFIRMADA"));
        return req.getId();
    }

    @Transactional
    public void cancelarReserva(String reservaId) {
        // ação de compensação
        Reserva r = reservaRepo.findById(reservaId);
        r.setStatus("CANCELADA");
        reservaRepo.save(r);
        // libera o quarto, etc.
    }
}

Se a saga falhar no meio, o orquestrador chama cancelarReserva para aquela reserva.

Dica de ouro: a ação de compensação também deve ser idempotente (se chamar duas vezes, não faz bagunça). E idealmente, ela nunca falha – mas se falhar, você entra com um processo manual ou fila de dead letter.

3️⃣ Idempotência – pra não repetir a mesma besteira duas vezes

Idempotência é a chave de tudo. Se você não sabe se uma mensagem vai chegar uma ou duas vezes (e no mundo distribuído, ela vai chegar duas vezes), você precisa garantir que o efeito seja o mesmo.

Como implementar: Idempotency Key (também chamada de requestId ou transactionId).

@PostMapping("/pedidos")
public ResponseEntity criarPedido(@RequestBody PedidoReq req, 
                                  @RequestHeader("Idempotency-Key") String idempotencyKey) {

    // Tabela de operações já processadas
    if (processedOperationRepo.existsById(idempotencyKey)) {
        Pedido pedido = processedOperationRepo.getResult(idempotencyKey);
        return ResponseEntity.ok(pedido); // retorna o mesmo resultado de antes
    }

    // Processa normalmente
    Pedido novoPedido = pedidoService.criar(req);

    // Guarda a chave + resultado (na mesma transação!)
    processedOperationRepo.save(new ProcessedOperation(idempotencyKey, novoPedido));

    return ResponseEntity.ok(novoPedido);
}

Boa prática: a chave de idempotência é gerada pelo cliente (UUID, por exemplo). O servidor só guarda a primeira execução. Qualquer requisição com a mesma chave retorna o resultado em cache.

4️⃣ Transactional Outbox – não perca mensagens (nunca mais)

Quando você salva algo no banco e precisa publicar um evento (tipo "PedidoCriado"), o risco é clássico: você salva no banco, mas antes de publicar o evento o serviço morre. O evento nunca vai pro Kafka, e ninguém sabe que o pedido existe.

A solução é a tabela Outbox (sim, o mesmo padrão do post anterior, mas agora aplicado dentro do serviço):

CREATE TABLE outbox (
    id UUID PRIMARY KEY,
    aggregate_id VARCHAR(100),
    event_type VARCHAR(50),
    payload JSONB,
    created_at TIMESTAMP,
    status VARCHAR(20) DEFAULT 'PENDING'
);

Na mesma transação do seu negócio, você insere o evento na tabela outbox:

@Transactional
public void criarPedido(PedidoReq req) {
    // 1. Salva o pedido
    pedidoRepo.save(pedido);

    // 2. Salva o evento na outbox (MESMA transação)
    OutboxEvent event = new OutboxEvent(
        UUID.randomUUID(),
        pedido.getId(),
        "PedidoCriado",
        json(pedido)
    );
    outboxRepo.save(event);
}

Depois, um Message Relay (pode ser um scheduler, Debezium, ou um worker) lê da tabela outbox e publica no Kafka/RabbitMQ, marcando como PUBLISHED.

@Scheduled(fixedDelay = 5000)
public void publicarEventos() {
    List<OutboxEvent> pending = outboxRepo.findByStatus("PENDING");
    for (OutboxEvent event : pending) {
        try {
            kafkaTemplate.send(event.getTopic(), event.getPayload());
            event.setStatus("PUBLISHED");
            outboxRepo.save(event);
        } catch (Exception e) {
            // log e tenta de novo depois
        }
    }
}

Garantia: O evento só não será publicado se o serviço morrer antes do commit da transação (mas aí o pedido também não foi salvo). Consistência garantida.

5️⃣ Tabela de Estado ou Log – a memória da saga

Você precisa saber em que ponto cada saga está. Se uma saga falha, quem vai acordar e tentar compensar? Ou se um serviço ficou fora do ar, como retomar?

Crie uma tabela de estado da saga:

CREATE TABLE saga_state (
    saga_id UUID PRIMARY KEY,
    tipo VARCHAR(50),          -- ex: "CRIAR_PEDIDO"
    estado VARCHAR(20),        -- STARTED, STEP1_OK, STEP2_OK, COMPLETED, FAILED
    dados_payload JSONB,       -- contexto da saga
    created_at TIMESTAMP,
    updated_at TIMESTAMP
);

Cada vez que a saga avança, você atualiza o estado (na transação local do passo atual).

Se um passo falha, a saga fica em FAILED. Um processo background (ou o próprio orquestrador) pode reler sagas travadas há muito tempo e executar compensações ou retentativas.

Exemplo de scheduler de monitoramento:

@Scheduled(fixedDelay = 60000)
public void recuperarSagasTravadas() {
    List<SagaState> travadas = sagaStateRepo.findByEstadoInAndUpdatedAtLessThan(
        List.of("STEP1_OK", "STEP2_OK"),
        LocalDateTime.now().minusMinutes(30)
    );

    for (SagaState saga : travadas) {
        log.warn("Saga {} travada no estado {}. Executando compensação...", saga.getId(), saga.getEstado());
        orquestrador.compensar(saga);
    }
}

🧭 Fluxo de decisão: qual técnica usar quando?

Seu problema	Técnica principal
Coordenar vários serviços em uma operação distribuída	Saga Pattern (orquestração ou coreografia)
Preciso desfazer algo que já foi feito	Mecanismo de compensação (ações reversas)
O mesmo comando pode chegar duas vezes (e isso é normal)	Idempotência com chave única
Preciso publicar eventos sem risco de perder mensagem	Transactional Outbox
Saga pode ficar travada e preciso monitorar	Tabela de estado + scheduler de recuperação
Tudo isso junto	Combão: Saga orquestrada + idempotência + outbox + tabela de estado

⚡ Dicas quentes que ninguém conta

1. Compensação não é trivial

Projetar uma ação reversa que sempre funciona é difícil. Por exemplo, se você enviou um e-mail, não dá pra "desenviar". Nesse caso, a compensação pode ser enviar outro e-mail informando o cancelamento.

2. Idempotência tem prazo de validade

Sua tabela de chaves de idempotência vai crescer para sempre. Crie um job que limpa chaves com mais de X dias (ex: 30 dias), a menos que você precise de histórico eterno.

3. Outbox com polling pode ter lag

Se você usa um scheduler simples, seu evento pode demorar alguns segundos para ser publicado. Se precisar de latência baixa, use Debezium (CDC) que reage quase em tempo real.

4. Sagas orquestradas viram ponto único?

O orquestrador pode cair no meio. Nesse caso, você precisa que ele seja resiliente (várias instâncias, persistência de estado, e capacidade de retomar onde parou). A tabela saga_state é fundamental aqui.

5. Coreografia é linda, mas difícil de debugar

Quando tudo é evento, ninguém tem visão completa. Coloque correlation IDs em cada mensagem e use um sistema de tracing (Jaeger, Zipkin) para seguir o fluxo.

💬 Conclusão – ACID morreu, viva a BASE (com planejamento)

Sistemas não transacionais (bancos NoSQL, microsserviços, filas) não te dão rollback mágico. Mas isso não significa que você está condenado à inconsistência. As técnicas que vimos aqui – Saga Pattern, compensação, idempotência, outbox e tabela de estado – são o arsenal moderno para garantir consistência eventual de forma robusta.

Lembre-se:

Transação grande? Quebre em sagas.
Falhou no meio? Compense o que foi feito.
Mensagem repetida? Idempotência resolve.
Precisa publicar evento? Outbox salva.
Saga travou? Tabela de estado + scheduler recupera.

Agora é sua vez: já implementou alguma saga na raça? Já perdeu evento porque não usava outbox? Me conta nos comentários. E se ainda não precisou, já sabe onde mirar quando o sistema crescer. Bora codar com menos medo de consistência e mais arquitetura pensada! 🛡️🔥

Quer aprofundar? No próximo post vou mostrar um exemplo prático completo de saga orquestrada com Spring Boot, Kafka e Debezium. Até lá!

🎬 O Guia basico sobre Optimistic vs Pessimistic Lock no Spring Boot 🍿

Fabio Rocha — Wed, 08 Jul 2026 22:56:09 +0000

Você já tentou comprar o último ingresso pro filme mais hypado do ano, viu a mensagem "Reserva Confirmada", mas na hora do pagamento o sistema disse que o assento estava ocupado? Pois é. A vida de quem desenvolve sistemas de reserva é exatamente assim, mas no lugar do usuário frustrado, nós temos transações concorrentes e o temido estado de corrida (race condition). Vamos descobrir como o Spring Boot resolve essa briga usando Optimistic e Pessimistic Locking, com aquele case clássico de reserva de assentos de cinema. 🎟️

🔐 O Desafio: O Último Ingresso

Imagina que temos uma tabela SeatDetails com o campo isBooked (status do assento). Se 100 pessoas tentarem marcar o assento A1 ao mesmo tempo, sem controle, várias vão ler "disponível" e tentar atualizar ao mesmo tempo. Resultado: sobreposição de dados, ticket vendido duas vezes e uma baita dor de cabeça.

Aí entram os Locking Strategies para garantir que a venda seja atômica e consistente.

⚡ 1. Optimistic Locking (O "Achismo" Otimista)

O otimista não segura a porta. Ele deixa todo mundo tentar, mas na hora de finalizar, ele confere se alguém passou na frente.

Como funciona?
Adicionamos um campo version na entidade com a anotação @Version. Quando alguém atualiza o assento, o JPA incrementa a versão.

@Entity
public class SeatDetails {
    @Id
    private Long id;
    private boolean isBooked;
    @Version
    private Long version; // O segredo está aqui!
    // getters e setters
}

Na Prática:
1. Usuário A e B leem o assento (versão = 1).
2. A atualiza e commita (versão vira 2).
3. B tenta atualizar baseado na versão 1.
4. Resultado: O Hibernate lança um OptimisticLockException. B perdeu, mas não bagunçou o banco.
Quando usar? Em cenários de baixa concorrência (edição de perfil de usuário, por exemplo).

🛡️ 2. Pessimistic Locking (O "Chato" Pragmático)

O pessimista trava a porta na cara. Quando alguém entra para editar, ele tranca a fileira do cinema até terminar.

Como funciona?
Usamos o @Lock do Spring Data JPA com o modo PESSIMISTIC_WRITE. Ele manda o banco de dados executar um SELECT ... FOR UPDATE, travando a linha.

public interface SeatRepo extends JpaRepository<SeatDetails, Long> {
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT s FROM SeatDetails s WHERE s.id = :id")
    Optional<SeatDetails> findByIdWithPessimisticLock(@Param("id") Long id);
}

Na Prática:
1. Usuário A chama o método com @Transactional.
2. O banco trava a linha do assento A1.
3. Usuário B tenta ler o mesmo assento e fica na fila de espera (bloqueado) até A terminar.
4. O @Transactional garante que, ao final do processo, o lock seja liberado (commit ou rollback).
Quando usar? Em cenários de alta concorrência e disputa feroz (leilões, Black Friday, estoque final).

🚀 3. O Novo Ator no Pedaço: RedLock com Redis (Quando o Banco Não Dá Conta do Gole)

E quando sua aplicação já cresceu tanto que tem várias instâncias rodando (microserviços em containers, serverless) e você precisa coordenar a reserva do assento entre diferentes serviços, não só entre threads de uma única JVM?

É aí que o banco de dados sozinho já não resolve mais. O Pessimistic Lock funciona lindamente dentro da mesma instância do banco, mas se o assento A1 for acessado por APIs diferentes que usam bancos diferentes? Ou se seu serviço for stateless (tipo um Lambda) e não segurar uma transação de banco aberta por muito tempo? Você precisa de um Distributed Lock, e aí entra o RedLock.

Pense no RedLock como o segurança trancando não apenas uma porta, mas todas as saídas de emergência do cinema. Ele impede que qualquer instância do seu sistema, rodando em qualquer lugar, mexa no recurso ao mesmo tempo.

Mas por que não usar um simples SETNX do Redis? Porque se o nó master do Redis cair e você fizer failover para um Slave, o lock pode se perder. É como se o segurança trocasse de turno no meio da briga e esquecesse quem estava com a chave. O RedLock resolve isso usando vários master independentes. Para conseguir a chave, o cliente precisa convencer a maioria deles (mais da metade) simultaneamente. Só assim ele garante que o lock é verdadeiro e que não vai sumir.

Na prática, você teria 5 masters Redis completamente separados (em máquinas diferentes). Para trancar o assento, o cliente:

Marca o horário que começou a tentar.
Tenta trancar o mesmo recurso em todos os 5 masters (com um tempo de validade curto, tipo 30 segundos).
Se conseguir trancar na maioria (pelo menos 3), o lock é dele. E o tempo que ele realmente pode usar o lock é o tempo total inicial menos o tempo que ele gastou tentando.
Se falhar, ele libera os locks que conseguiu em qualquer nó e tenta de novo.

O Redisson (a biblioteca mais usada) faz quase tudo isso pra você. O código fica lindo:

// Adicione no seu pom.xml
<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.16.1</version>
</dependency>

// No seu serviço...
@Service
public class ReservaService {

    @Autowired
    private RedissonClient redissonClient;

    public void reservarAssento(String assentoId) {
        RLock lock = redissonClient.getLock("lock:assento:" + assentoId);
        if (lock.tryLock()) {
            try {
                // Só UM cliente (ou instância) por vez entra aqui!
                // Verifica se o assento ainda está livre
                // Reserva o assento
                // Salva a reserva no banco
            } finally {
                lock.unlock(); // Não esquece de liberar!
            }
        } else {
            throw new RuntimeException("Assento ocupado, tente novamente!");
        }
    }
}

Mas atenção! O RedLock não é bala de prata. O famoso Martin Kleppmann (autor de Designing Data-Intensive Applications de onde eu tirei parte desse texto kkkk 🤫) tem uma baita crítica a ele: o RedLock assume que o relógio de todas as máquinas está perfeitamente sincronizado. No mundo real, com clock drift (relógio atrasando ou adiantando) ou pausas longas de Garbage Collector, um lock pode expirar antes da hora, dando a impressão que o recurso está livre quando na verdade ainda está sendo usado. Se você precisa de correção absoluta (ex: transferência bancária), o RedLock pode ser arriscado.

🤔 Quando Usar RedLock?

Cenário	Recomendação
Seu sistema é uma única aplicação Spring	Fique com Optimistic/Pessimistic Lock.
Você precisa de PERFORMANCE e tolera falhas raras (ex: um job duplicado num cache)	Use Redis simples com `SETNX`.
Você precisa de CORREÇÃO ABSOLUTA (ex: débito em conta bancária)	Esqueça RedLock. Use ZooKeeper, etcd ou um banco relacional com transações fortes.
Cenário híbrido: vários microserviços e precisão moderada	RedLock pode ser um bom caminho, mas entenda os riscos.

📊 Tabela Rápida: Qual devo usar?

Característica	Optimistic Lock	Pessimistic Lock	RedLock (Redis)
Estratégia	"Tenta aí, se falhar, tenta de novo."	"Tranca tudo, depois você mexe."	"Tranca em múltiplos lugares antes de agir."
Bloqueio	Nenhum bloqueio enquanto lê.	Bloqueio físico no banco (`SELECT FOR UPDATE`).	Usa `SET NX` em vários masters.
Performance	Alta performance em leitura.	Performance menor (espera nas filas).	Rápida, mas requer ida em vários nós.
Melhor para	Leituras freq., escritas esporádicas.	Escritas freq. e muitos conflitos.	Ambientes Distribuídos (vários serviços).
Risco	Muitas exceções se a disputa for alta.	Deadlocks ou lentidão.	Clock drift e falhas de sincronização.
Código	Anotação `@Version` na entidade.	Anotação `@Lock` no Repository.	Biblioteca Redisson ou cliente específico.

💡 Dica de Implementação (para não errar no código)

Optimistic: Se você receber uma OptimisticLockException, é legal tratar isso na camada de serviço. Dá pra tentar uma retentativa automática (reler os dados e tentar salvar de novo) ou avisar o usuário: "Ops, alguém alterou esse dado. Recarregue a tela."
Pessimistic: Lembre-se sempre de rodar dentro de um método @Transactional. Se você só fizer o findByIdWithPessimisticLock e não tiver o @Transactional, o lock morre sozinho.

🎯 Conclusão (Na Pipoca)

O Optimistic Locking é perfeito para quando a briga é rara. É leve, rápido e não entope o banco. O Pessimistic Locking é aquele segurança que trava a catraca em shows lotados: trava o banco, mas garante que ninguém vai invadir o assento. E o RedLock com Redis é o segurança que coordena vários portões de diferentes cinemas da rede: ideal quando seus serviços estão todos espalhados, mas tem suas controvérsias e não é a bala de prata para precisão extrema.

No final das contas, não existe bala de prata. A escolha depende do seu negócio: quantas pessoas vão disputar esse assento ao mesmo tempo? Se for um filme do Pelé em dia de estreia, melhor preparar o lock e o Refri.

😉 Gostou? Tem um sistema de reservas aí na sua empresa? Já usou RedLock? Conta aí nos comentários qual dessas estratégias você mais usa e se já sofreu com algum lock. 🚀

Virtual Threads – adeus, `OutOfMemoryError`; olá, milhões de threads

Fabio Rocha — Wed, 10 Jun 2026 16:38:02 +0000

E aí, dev que vive de ExecutorServicee CompletableFuture? Já tentou criar 10 mil threads na mão? O OutOfMemoryError vem cantando. Isso porque as threads clássicas do Java (agora chamadas de platform threads) são, basicamente, wrappers finos de threads do sistema operacional. Elas são caras – cada uma consome cerca de 20 MB de memória só de pilha (stack).

Mas a partir do JDK 21, temos as virtual threads – leves, baratas. Vamos entender sem mistério.

⚠️ Qual é o problema das Platform Threads (as de sempre)?

Uma thread de plataforma = uma thread do SO.

Isso é caro em tempo (criação lenta) e espaço (stack enorme: ~20 MB).

O escalonador do SO também tem trabalho para trocar o contexto entre elas.

Faça as contas: numa máquina com 8 GB de RAM, cabem no máximo umas 400 threads (8.000 MB / 20 MB = 400). Se essas threads ficarem a maior parte do tempo esperando I/O (como acesso a banco, chamadas HTTP), o CPU fica ocioso – você mal usa o hardware.

Exemplo: uma thread trabalha 0,001 ms preparando um request, depois espera 100 ms pela resposta da rede. Nesse cenário, ela fica parada 99,99% do tempo. Com 400 threads, o uso de CPU é menor que 1%. Um desperdício.

A solução tradicional? Usar pools de threads, CompletableFuture, programação reativa (Mono/Flux). Mas o código fica mais complexo, cheio de callbacks.

✨ Virtual Threads – a revolução

Virtual threads são leves – cada uma ocupa poucos bytes (não megabytes) e vivem no heap da JVM, não na pilha do SO. Criar uma virtual thread é ~1000 vezes mais barato que uma platform thread. Elas são gerenciadas pelo próprio JVM, não pelo escalonador do SO.

A arquitetura é de muitos para poucos: milhões de virtual threads rodam em cima de um pequeno número de platform threads (as velhas conhecidas). Cada platform thread executa uma virtual thread por vez, e quando a virtual thread bloqueia (ex: aguardando I/O), a JVM desmonta ela dali e a platform thread pega outra virtual thread pronta. Isso chama-se escalonamento cooperativo – ninguém fica parado.

📌 Nota importante:

Virtual threads não devem ser pooladas nem reutilizadas. São descartáveis, baratas, criamos uma para cada tarefa concorrente e pronto.

🛠️ Criando e usando virtual threads na prática

Vamos pegar uma tarefa simples:

Runnable task = () -> System.out.println(
    Thread.currentThread().toString());

1. Criar e já iniciar com `startVirtualThread()`

Thread vThread = Thread.startVirtualThread(task);
vThread.setName("minhaVirtual");

2. Usando `Thread.ofVirtual()`

Thread vThread = Thread.ofVirtual().start(task);
// Com nome
Thread vThread = Thread.ofVirtual().name("minhaVirtual").start(task);

3. Usando `Thread.Builder` (útil para várias)

Thread.Builder builder = Thread.ofVirtual().name("vt-", 1);
Thread t1 = builder.start(task);
t1.join();
Thread t2 = builder.start(task);
t2.join();

4. Criar sem iniciar (`unstarted`)

Thread vThread = Thread.ofVirtual().unstarted(task);
// depois...
vThread.start();

5. `ThreadFactory` de virtual threads

ThreadFactory factory = Thread.ofVirtual().name("worker-").factory();
Thread vThread = factory.newThread(task);
vThread.start();

Fácil, né? Você usa a mesma API java.lang.Thread que já conhece. Não precisa aprender CompletableFuture ou reactive streams – o código fica sequencial e legível.

🔍 Detalhes que você precisa saber

isVirtual() → retorna true.
É daemon por padrão (isDaemon() = true). Não tente mudar.
Prioridade sempre NORM_PRIORITY (5). setPriority() não tem efeito.
Não pertence a ThreadGroup tradicional – o grupo se chama "VirtualThreads".
toString() mostra algo como: VirtualThread[#22]/runnable@ForkJoinPool-1-worker-1. O ForkJoinPool-1-worker-1 é a carrier thread (platform thread) que está executando sua virtual thread.

🚀 Quantas virtual threads conseguimos criar?

Rode isso (com cuidado, porque ele trava o sistema só depois de milhões):

AtomicLong contador = new AtomicLong();
while (true) {
    Thread.startVirtualThread(() -> {
        long id = contador.incrementAndGet();
        System.out.println("Virtual thread: " + id);
        LockSupport.park(); // trava a thread virtual
    });
}

No meu notebook, depois de 14 milhões de virtual threads o sistema ficou lento (GC atuando forte), mas não estourou memória. Isso é outro patamar de concorrência.

❗ Mitos que você deve esquecer

"Virtual threads são mais rápidas" – ERRADO. Elas não tornam código computacional mais rápido. Para CPU pesado, use parallel streams. Virtual threads melhoram throughput (você pode ter milhões esperando I/O), mas não latência.
"Devemos poolá-las" – ERRADO. Nunca crie um pool de virtual threads. Elas são descartáveis, baratas. Cada tarefa ganha a sua.
"Virtual threads são gratuitas" – ERRADO. Não são de graça, mas são 1000x mais baratas que platform threads.
"Se bloquear a virtual thread, a carrier thread também trava" – ERRADO. A JVM desmonta a virtual thread bloqueada e a carrier thread pega outra. O bloqueio não afeta outras virtual threads.

🔄 Compatibilidade retrógrada

Virtual threads funcionam com:

Blocos synchronized
ThreadLocal (mas cuidado com o número excessivo – pode não escalar)
Thread.currentThread()
interrupt() e InterruptedException

Ou seja, seu código antigo simplesmente roda em virtual threads – sem modificação. Basta mudar de new Thread(...).start() para Thread.startVirtualThread(...).

📌 Quando usar (e quando não usar)

✅ Ótimo para:

Muitas tarefas de I/O (chamadas HTTP, leitura de banco, acesso a arquivos)
Servidores web com alta concorrência
Substituir CompletableFuture e código reativo cheio de callbacks

❌ Não tão útil para:

Processamento intensivo de CPU (cálculos, criptografia, compressão) – prefira parallel streams ou manter pool de platform threads com tamanho = número de cores

🧠 Exemplo prático: simulando 10.000 chamadas HTTP

Com virtual threads fica limpo:

var httpClient = HttpClient.newHttpClient();
var requests = IntStream.range(0, 10_000)
    .mapToObj(i -> HttpRequest.newBuilder(URI.create("https://api.exemplo.com/users/" + i)).build())
    .toList();

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    var futures = requests.stream()
        .map(req -> executor.submit(() -> httpClient.send(req, BodyHandlers.ofString())))
        .toList();

    for (var future : futures) {
        var response = future.get();
        System.out.println(response.body().length());
    }
}

Criamos 10.000 virtual threads ao mesmo tempo, cada uma esperando I/O. Com platform threads, isso seria impossível sem um pool enorme e OutOfMemoryError. Com virtual threads, roda liso.

🎯 Conclusão

Virtual threads são um divisor de águas para concorrência em Java:

✔️ Crie milhões delas sem medo
✔️ Código simples e bloqueante (nada de callbacks)
✔️ Aproveite ao máximo o hardware em tarefas de I/O
✔️ Compatível com todo o ecossistema Java

Então da próxima vez que pensar em CompletableFuture ou reactive streams, pergunte-se: dá pra resolver com virtual threads? Muitas vezes, a resposta é sim – com muito menos neuras.

Gostou? Testa aí no seu código com JDK 21+ e me conta o que achou. E lembre-se: thread virtual não é mais rápida, mas você pode ter tantas que parece mágica. ✨

Java21 #VirtualThreads #Concorrência #ProgramaçãoAssíncrona #JDK

Quer mais? O próximo post vai mostrar como usar virtual threads com Spring Boot e comparar performance com reactive. Até lá!

Kafka sem duplicação – 2 padrões pra você dormir em paz

Fabio Rocha — Wed, 27 May 2026 19:57:38 +0000

🔁 Kafka sem duplicação – 3 padrões? Não, 2 bastam! (os que realmente funcionam)

E aí, pessoa desenvolvedora de microsserviços? Já teve pesadelo com mensagem duplicada no Kafka? Já processou o mesmo evento duas vezes e olhou pro banco de dados com aquele suor frio descendo a espinha? Pois é. Duplicação é a pedra no sapato de qualquer sistema distribuído.

Mas calma. Hoje a gente vai focar nos dois padrões que realmente resolvem o problema sem firula: Consumidor Idempotente e Transactional Outbox. Nada de Kafka Transaction API (que, entre nós, mais atrapalha do que ajuda quando tem banco relacional no meio). Pega um café, bora codar com menos susto e mais confiança! 🚀

O cenário clássico que dá pesadelo

Imagine que seu serviço consome uma mensagem de um tópico, faz o seguinte pipeline:

🔁 Faz um POST em uma API externa
💾 Insere um registro no banco de dados
📤 Publica um evento em um tópico de saída

Seu código consome a mensagem, processa e só depois de tudo isso commit do offset no Kafka.

Aí o sistema morre bem no meio. O que acontece? A mensagem ainda não foi marcada como consumida. Kafka acha que o consumidor morreu e rebalanceia a partição para outra instância, que vai pegar exatamente a mesma mensagem e processar de novo. Resultado: POST duplicado, INSERT duplicado, evento duplicado. E você na UTI do sistema às 3 da manhã. ☠️

Mas calma, que temos dois padrões matadores para resolver isso. Bora?

🔑 Padrão 1: Consumidor Idempotente

A ideia aqui é simples: seu consumidor pode receber a mesma mensagem várias vezes, mas só processa uma vez por meio de IDs únicos armazenados.

Como funciona na prática:

1. ID único (Idempotency Key): Sua mensagem precisa carregar um identificador único, tipo transactionId ou eventId. Esse ID pode vir no header do Kafka ou dentro do payload.

2. Tabela de mensagens processadas: No mesmo banco onde você faz as escritas do seu negócio, cria uma tabelinha "processed_messages" com a chave primária sendo esse ID.

3. Processamento atômico: Você insere o ID nessa tabela na mesma transação que as outras escritas do banco. Se der pau no meio, tudo rola junto!

@Transactional
public void processarEvento(ConsumerRecord<String, OrderEvent> record) {
    String eventId = record.headers().lastHeader("eventId");

    // Se já existe, é duplicata
    if (processedMessageRepo.existsById(eventId)) {
        log.info("📌 Evento {} já processado. Pulando!", eventId);
        return;
    }

    // Processa o negócio
    orderService.criarPedido(record.value());

    // Marca como processado na MESMA transação
    processedMessageRepo.save(new ProcessedMessage(eventId));
}

Se criarPedido falhar, a inserção na tabela processed_messages também rola de volta automaticamente. O @Transactional garante a atomicidade.

Vantagem: Simples, funciona com qualquer banco relacional.

Desvantagem: Não resolve sozinho a publicação atômica de eventos no Kafka (pra isso entra o padrão 2).

📦 Padrão 2: Transactional Outbox

Esse padrão resolve um outro problema clássico: você precisa publicar um evento no Kafka e gravar no banco de dados, mas as duas ações não podem ser atômicas usando o mesmo contexto transacional.

A solução é:

Tabela Outbox: Em vez de publicar direto no Kafka, você insere o evento em uma tabela outbox na mesma transação que suas escritas de negócio.
CDC (Change Data Capture): Ferramentas como Debezium monitoram a tabela outbox e publicam os eventos no tópico final de forma garantida e idempotente.

BEGIN;
  -- 1. Escrita de negócio
  INSERT INTO pedidos (id, valor, cliente_id) VALUES (123, 100.00, 1);

  -- 2. Evento vai pra tabela outbox (na mesma transação!)
  INSERT INTO outbox (aggregate_id, event_type, payload)
  VALUES (123, 'PedidoCriado', '{"valor": 100.00}');
COMMIT;

Com CDC, o evento vai parar no tópico final sem risco de inconsistência entre banco de dados e Kafka.

Vantagem: Publicação confiável e atômica com o banco.

Desvantagem: Requer infra adicional (Debezium, Kafka Connect), e o CDC pode ter latência de segundos.

👑 O combo campeão: consumidor idempotente + outbox

Agora junta os dois: o padrão 1 garante que a mesma mensagem não vai ser processada duas vezes no consumidor, e o padrão 2 garante que os eventos de saída serão publicados de forma confiável sem duplicação no lado do produtor.

Juntos, eles formam a base de qualquer microsserviço que se preze:

@Transactional
public void processarEventoIntegrado(ConsumerRecord<String, Evento> record) {
    // 1. Idempotent Consumer: verifica se já processou
    String eventId = record.headers().lastHeader("eventId");
    if (processedMessageRepo.existsById(eventId)) {
        return;
    }

    // 2. Chama API externa (não tem jeito, aqui pode dar duplicata)
    //    Mas aí é problema da API externa ser idempotente, não nosso :)
    apiExterna.criarRecurso(record.value().getDados());

    // 3. Escrita de negócio + outbox (tudo na mesma transação)
    pedidoService.criarPedido(record.value().getPedido());
    outboxRepo.save(criarEventoOutbox(record.value()));

    // 4. Marca como processado (ainda na mesma transação)
    processedMessageRepo.save(new ProcessedMessage(eventId));
}

Pronto. Você dorme em paz.

⚠️ Melhores práticas e dicas quentes que ninguém conta

1.🔑 Idempotency Keys bem feitas

UUID gerado no cliente: Mais seguro. O produtor gera, e o ID viaja até o consumidor.
Chave composta de negócio: Exemplo: customerId:orderId:timestamp. Funciona se a combinação for verdadeiramente única.
Coordenadas do Kafka: Usar topic-partition-offset como ID. Simples, mas quebra se você reproduzir o evento a partir de um tópico diferente.

2.⏱️ Cuidado com timeouts e rebalanceamento

Configuração max.poll.interval.ms e max.poll.records precisa estar alinhada com o tempo médio de processamento do seu lote. Se o consumidor demorar demais e não conseguir chamar poll() dentro do tempo, o broker acha que ele morreu e redistribui as partições – causando reprocessamento.

3.🧹 Limpeza da tabela `processed_messages`

Essa tabela pode crescer infinitamente. Crie uma rotina de limpeza assíncrona (ex: job diário que apaga registros com mais de 7 dias).

4.🧪 Outbox com polling simples (sem CDC)

Se você não quiser usar Debezium, pode implementar um polling publisher – um scheduler que lê da tabela outbox e publica no Kafka em lotes. Mas aí você assume responsabilidade de idempotência e transação.

5.🚫 O que não fazer

Não tente coordenar transações entre Kafka e banco com XA ou JTA. É lento, frágil e geralmente um pesadelo.
Não use Kafka Transaction API junto com transações de banco. Já vimos que a combinação não é atômica e pode causar perda de dados.

🧭 Fluxo de decisão: qual padrão escolher?

Você só precisa gravar no banco e ponto?
  ├─ Banco relacional → Idempotent Consumer com tabela processed_messages
  └─ NoSQL (Redis, MongoDB) → Use lock distribuído (SETNX) ou tabela auxiliar

Você precisa gravar no banco E publicar eventos no Kafka:
  ├─ Tem budget e infra para CDC (Debezium)? → Transactional Outbox + Idempotent Consumer (recomendado)
  ├─ Quer algo mais leve sem CDC? → Outbox com polling + Idempotent Consumer
  └─ Precisa de latência baixíssima (milissegundos)? → Idempotent Consumer + transação manual com idempotent producer (cuidado!)

Cenário ideal para microsserviços críticos:
  ✅ Idempotent Consumer + Transactional Outbox (com CDC)

💬 Dúvida comum: por que não usar Kafka Transaction API?

Essa pergunta aparece muito. A resposta direta: Kafka Transaction API foi feita para cenários de stream processing onde a única fonte de verdade é o próprio Kafka (ex: Kafka Streams). Quando você tem um banco relacional no meio, tentar unir as duas transações não traz atomicidade real e ainda introduz complexidade sem necessidade.

Os padrões 1 e 2 resolvem o problema de forma comprovada, com ferramentas maduras (Debezium, PostgreSQL, etc.) e sem surpresas. Por que inventar moda? 😎

🎯 Conclusão

Duplicação de mensagem não é questão de "se" vai acontecer, mas de "quando". As garantias de "at-most-once" e "at-least-once" do Kafka são otimistas demais para sistemas reais. O que salva é o design idempotente do seu consumidor.

Lembre-se:

A base de tudo é o Idempotent Consumer (eventId + tabela de controle)
O Transactional Outbox garante a publicação confiável de eventos sem duas fases de commit
O combo Idempotent Consumer + Outbox é o mais recomendado, robusto e dorme-se em paz
Esqueça Kafka Transaction API se você tem banco de dados – não é pra você

Agora é sua vez: já passou por algum apagão de duplicação? Me conta nos comentários como resolveu. E se ainda não passou, já sabe onde mirar quando o caos chegar. Bora codar com menos duplicata e mais paz de espírito! 🛡️🔥

Quer mais conteúdo sobre Kafka, arquitetura de microsserviços e resiliência? Segue o blog e ativa as notificações – o próximo post vai ser sobre "Dead Letter Queues e como não perder eventos". Não perde!

Trabalhando com mapMulti() – Transforme seus streams sem neuras

Fabio Rocha — Wed, 20 May 2026 18:17:18 +0000

Trabalhando com `mapMulti()` – Transforme seus streams sem neuras

E aí, dev? Tudo certo?

Se você está no JDK 16 ou superior, a Stream API ganhou um novo brinquedo: o método mapMulti(). Ele parece meio estranho no começo, mas juro que depois que você entende, começa a usar até pra fazer café ☕.

A ideia é simples: ele permite mapear cada elemento do stream para zero, um ou vários elementos novos, tudo dentro de um único BiConsumer. Chega de ficar encadeando filter() e map() que nem louco? Bom, nem sempre, mas em muitos casos sim. Vamos ver na prática.

🔍 Exemplo clássico vs `mapMulti()`

Imagina que você tem uma lista de notas de alunos e quer filtrar só as notas maiores ou iguais a 7 e aplicar um bônus de 10% em cada uma.

Modo tradicional (filter + map):

List<Double> notas = List.of(5.5, 8.0, 6.0, 9.5, 7.0, 4.0);

List<Double> notasComBonus = notas.stream()
    .filter(n -> n >= 7)
    .map(n -> n * 1.10)
    .collect(Collectors.toList());

// Resultado: [8.8, 10.45, 7.7]

Agora com mapMulti() a gente faz a mesma coisa com uma só operação:

List<Double> notasComBonusMM = notas.stream()
    .<Double>mapMulti((nota, consumer) -> {
        if (nota >= 7) {
            consumer.accept(nota * 1.10);
        }
    })
    .collect(Collectors.toList());

O if faz o papel do filter(), e o accept() aplica o map().

Perceba o .<Double> antes do mapMulti – isso é um type-witness (o compilador chato pediu). Sem ele o código não compila. Um pequeno preço a pagar.

🧮 Trabalhando com tipos primitivos – `mapMultiToDouble()`

Se a sua ideia é somar essas notas com bônus, melhor usar a versão especializada para double:

double somaComBonus = notas.stream()
    .mapMultiToDouble((nota, consumer) -> {
        if (nota >= 7) {
            consumer.accept(nota * 1.10);
        }
    })
    .sum();

System.out.println(somaComBonus); // 26.95

Sem type-witness, sem firula. E se depois você quiser voltar a ter um Stream<Double>, é só usar boxed() ou mapToObj():

Stream<Double> streamBonus = notas.stream()
    .mapMultiToDouble((nota, consumer) -> {
        if (nota >= 7) consumer.accept(nota * 1.10);
    })
    .boxed();

📦 `flatMap()` vs `mapMulti()` – o duelo do one‑to‑many

Vamos para um exemplo mais real. Temos categorias de produtos, e cada categoria tem vários produtos. Queremos gerar uma lista simples de ProdutoInfo contendo o nome da categoria + o nome do produto.

class Categoria {
    private String nome;
    private List<Produto> produtos;
    // getters...
}

class Produto {
    private String nome;
    private double preco;
    // getters...
}

class ProdutoInfo {
    private String categoria;
    private String produto;
    // construtor, getters...
}

Com `flatMap()` (tradicional)

List<ProdutoInfo> listaFlat = categorias.stream()
    .flatMap(cat -> cat.getProdutos().stream()
        .map(prod -> new ProdutoInfo(cat.getNome(), prod.getNome()))
    )
    .collect(Collectors.toList());

O problema aqui é que, para cada categoria, criamos um stream intermediário (o cat.getProdutos().stream()). Se forem muitas categorias, isso pesa.

Com `mapMulti()` (mais enxuto)

List<ProdutoInfo> listaMM = categorias.stream()
    .<ProdutoInfo>mapMulti((categoria, consumer) -> {
        for (Produto p : categoria.getProdutos()) {
            consumer.accept(new ProdutoInfo(categoria.getNome(), p.getNome()));
        }
    })
    .collect(Collectors.toList());

Sem streams intermediários, só um laço for simples. Mais performático e, na minha opinião, mais fácil de ler.

🎯 Com filtro adicional – só produtos acima de R$ 50

Se você quiser só produtos com preço maior que 50, a vantagem do mapMulti() fica ainda mais clara:

List<ProdutoInfo> listaCaros = categorias.stream()
    .<ProdutoInfo>mapMulti((categoria, consumer) -> {
        for (Produto p : categoria.getProdutos()) {
            if (p.getPreco() > 50) {
                consumer.accept(new ProdutoInfo(categoria.getNome(), p.getNome()));
            }
        }
    })
    .collect(Collectors.toList());

Aqui você evita um filter() extra e mantém tudo no mesmo lugar. E repara: cada categoria tem poucos produtos (geralmente), então se encaixa perfeitamente na recomendação oficial:

Use mapMulti() quando for substituir cada elemento do stream por um pequeno número (possivelmente zero) de elementos.

🧠 Abordagem imperativa? Também vale!

Sabe aquele método que já faz a lógica toda e recebe um Consumer? Então... você pode passar ele direto pro mapMulti().

Adicione na classe Categoria:

public void produtosCaros(Consumer<ProdutoInfo> consumer, double limite) {
    for (Produto p : this.produtos) {
        if (p.getPreco() > limite) {
            consumer.accept(new ProdutoInfo(this.nome, p.getNome()));
        }
    }
}

Agora seu stream fica limpo igual água de coco:

List<ProdutoInfo> resultado = categorias.stream()
    .<ProdutoInfo>mapMulti(cat -> cat.produtosCaros(consumer, 50))
    .collect(Collectors.toList());

Ou usando method reference (ainda mais lindo):

.<ProdutoInfo>mapMulti(cat -> cat.produtosCaros(consumer, 50))
// ou, se o limite for fixo:
.<ProdutoInfo>mapMulti(cat -> cat.produtosCaros(consumer, 50))

(Na real com method reference você teria que adaptar, mas a ideia é que o mapMulti aceita um lambda que chama seu método imperativo.)

✅ Quando usar `mapMulti()` – resumo da ópera

Você tem uma relação one‑to‑zero/one‑to‑many e o número de elementos gerados por elemento original é pequeno.
Quer evitar criar streams intermediários (melhor performance em laços grandes).
O código fica mais claro com um laço for e if do que com flatMap + filter + map.
Você já tem um método que recebe Consumer e quer integrar direto no stream.

O mapMulti() não vai matar o flatMap() – cada um tem seu lugar. Mas quando o cenário se encaixa, é como trocar uma chave de fenda por uma chave Philips: faz o mesmo serviço, mas com muito mais estilo.

Gostou? Testa aí no seu código e me conta se os streams ficaram mais limpos. Até a próxima, e bora codar com menos firula e mais resultado! 🚀

DEV Community: Fabio Rocha

🧵 ThreadLocal no Java 21 – o que mudou, o que continua e quando você deve (ou não) usar

🔍 O que é ThreadLocal (e por que você usava isso)?

⚠️ Os problemas clássicos do ThreadLocal (que todo mundo já sofreu)

1. 💀 Memory Leak

2. 🔄 Contaminação entre requisições

3. 🧪 Dificuldade de testar

4. 🌍 Global state disfarçado

🧵 O problema com Virtual Threads

✨ A novidade do Java 21: Scoped Values

📊 Comparativo rápido

🧭 Quando usar cada um?

✅ Use ThreadLocal se:

✅ Use ScopedValue se:

❌ Evite ThreadLocal se:

💡 Dica de ouro

🎯 Conclusão

Java21 #VirtualThreads #ThreadLocal #ScopedValue #Concorrência

"Sistemas não transacionais? Sim, dá pra ter consistência (sem surtar)" – O guia do Saga Pattern, Outbox e idempotência

🧠 O problema clássico: você não está mais no seu banco relacional

1️⃣ Saga Pattern – quebre a transação grande em pedaços pequenos

🎭 Coreografia (cada serviço faz sua parte e emite eventos)

🎼 Orquestração (um serviço central manda em tudo)

2️⃣ Mecanismo de Compensação – o seu rollback manual

3️⃣ Idempotência – pra não repetir a mesma besteira duas vezes

4️⃣ Transactional Outbox – não perca mensagens (nunca mais)

5️⃣ Tabela de Estado ou Log – a memória da saga

🧭 Fluxo de decisão: qual técnica usar quando?

⚡ Dicas quentes que ninguém conta

1. Compensação não é trivial

2. Idempotência tem prazo de validade

3. Outbox com polling pode ter lag

4. Sagas orquestradas viram ponto único?

5. Coreografia é linda, mas difícil de debugar

💬 Conclusão – ACID morreu, viva a BASE (com planejamento)

🎬 O Guia basico sobre Optimistic vs Pessimistic Lock no Spring Boot 🍿

🔐 O Desafio: O Último Ingresso

⚡ 1. Optimistic Locking (O "Achismo" Otimista)

🛡️ 2. Pessimistic Locking (O "Chato" Pragmático)

🚀 3. O Novo Ator no Pedaço: RedLock com Redis (Quando o Banco Não Dá Conta do Gole)

🤔 Quando Usar RedLock?

📊 Tabela Rápida: Qual devo usar?

💡 Dica de Implementação (para não errar no código)

🎯 Conclusão (Na Pipoca)

Virtual Threads – adeus, `OutOfMemoryError`; olá, milhões de threads

⚠️ Qual é o problema das Platform Threads (as de sempre)?

✨ Virtual Threads – a revolução

🛠️ Criando e usando virtual threads na prática

1. Criar e já iniciar com startVirtualThread()

2. Usando Thread.ofVirtual()

3. Usando Thread.Builder (útil para várias)

4. Criar sem iniciar (unstarted)

5. ThreadFactory de virtual threads

🔍 Detalhes que você precisa saber

🚀 Quantas virtual threads conseguimos criar?

❗ Mitos que você deve esquecer

🔄 Compatibilidade retrógrada

📌 Quando usar (e quando não usar)

✅ Ótimo para:

❌ Não tão útil para:

🧠 Exemplo prático: simulando 10.000 chamadas HTTP

🎯 Conclusão

Java21 #VirtualThreads #Concorrência #ProgramaçãoAssíncrona #JDK

Kafka sem duplicação – 2 padrões pra você dormir em paz

🔁 Kafka sem duplicação – 3 padrões? Não, 2 bastam! (os que realmente funcionam)

O cenário clássico que dá pesadelo

🔑 Padrão 1: Consumidor Idempotente

Como funciona na prática:

📦 Padrão 2: Transactional Outbox

👑 O combo campeão: consumidor idempotente + outbox

⚠️ Melhores práticas e dicas quentes que ninguém conta

1.🔑 Idempotency Keys bem feitas

2.⏱️ Cuidado com timeouts e rebalanceamento

3.🧹 Limpeza da tabela processed_messages

4.🧪 Outbox com polling simples (sem CDC)

5.🚫 O que não fazer

🧭 Fluxo de decisão: qual padrão escolher?

💬 Dúvida comum: por que não usar Kafka Transaction API?

🎯 Conclusão

Trabalhando com mapMulti() – Transforme seus streams sem neuras

1. Criar e já iniciar com `startVirtualThread()`

2. Usando `Thread.ofVirtual()`

3. Usando `Thread.Builder` (útil para várias)

4. Criar sem iniciar (`unstarted`)

5. `ThreadFactory` de virtual threads

3.🧹 Limpeza da tabela `processed_messages`

Trabalhando com `mapMulti()` – Transforme seus streams sem neuras

🔍 Exemplo clássico vs `mapMulti()`

🧮 Trabalhando com tipos primitivos – `mapMultiToDouble()`

📦 `flatMap()` vs `mapMulti()` – o duelo do one‑to‑many

Com `flatMap()` (tradicional)

Com `mapMulti()` (mais enxuto)

✅ Quando usar `mapMulti()` – resumo da ópera