DEV Community: João Antônio

Como criar tarefas concorrentes no Java, feito por quem se preocupa com os recursos e performance

João Antônio — Tue, 01 Sep 2026 01:50:52 +0000

Este post nasce de uma preocupação que tenho levado cada vez mais a sério: entender como cada parte do código realmente impacta o uso de recursos.

Também tenho usado IA como ferramenta de estudo, principalmente para conseguir acompanhar tanta coisa nova sendo lançada sem perder o foco no que realmente quero aprender.

Este e outros textos que venho escrevendo também servem como um compromisso comigo mesmo: continuar estudando, escrevendo e tentando entender as coisas de verdade, em vez de apenas consumir informação de forma passiva. No fim, é uma tentativa de não perder esse contato racional com o aprendizado em um mundo onde tudo está fácil demais de acessar e onde é muito fácil começar o dia já sobrecarregando o córtex pré-frontal com dezenas de assuntos diferentes.

Então vou aqui apenas fomentar o assunto, e você se dispõe a continuar procurando caso queira, variações de implementação, interpretação ou até mesmo contrapor o que eu estou propondo aqui.

Então vamos lá, o primeiro ponto é entender como o projeto Loom no Java trouxe maturidade pro ciclo de vida de recursos de unidades de processamento, traduzindo, colocou threads controladas pela JVM muito mais leves onde você não precisa passar o controle para o kernel em IO's e deixar a thread dormindo esperando que a volta no socket de rede acorde sua thread para continuar rodando.

Como esse é um estudo deliberado que acontece após o expediente de trabalho e praticamente no último mês dedico meu tempo a entender todas as motivações e decisões de design da linguagem Java, tenho flertado muito com a programação funcional dado os estudos de números primos e logaritmo discreto, e algumas coisas que me preocuparam foi a dificuldade de criar vínculos de tarefas paralelas no Java, muitos só criam um pool e executam em paralelo, mas e se eu precisar vincular uma tarefa a outra de forma paralela, e se eu precisar cancelar e parar a outra também e não onerar recursos ou segurar recursos, como objetos parados na heap sem coleta, pool de conexão de banco segurando mais que o necessário, chamadas para outros serviços que poderiam ser abortadas (aqui vale estudar RPC, remote procedure call, para cancelamento de tarefas em sistemas distribuídos), exemplo de um código rudimentar:

var a = pool.submit(() -> antifraude(transacao));
var b = pool.submit(() -> limite(conta));
return new Autorizacao(a.get(), b.get());

A falhou? B continua rodando.

Agora imagine que você quer executar algumas tarefas em paralelo e que elas formem uma unidade só, ou todas servem ou nenhuma serve, que é exatamente o caso de uma autorização de cartão, onde antes de responder aprovado ou negado você precisa do score de antifraude, da checagem de limite na conta e da consulta de token na bandeira, cada uma vindo de um lugar diferente e todas dentro de uma janela de resposta apertada, porque a bandeira não vai esperar você para sempre. Para não ficar no achismo eu montei um cenário e medi, com o antifraude levando 300ms e retornando certo, a bandeira levando 250ms e retornando certo, e o autorizador de limite falhando aos 50ms. Aos 50ms a resposta já está condenada, essa transação vai ser negada de qualquer jeito, e a pergunta que interessa é o que acontece nos 250ms seguintes:

[ 50 ms] LIMITE falha (a exceção fica guardada calada dentro do Future)
[300 ms] ANTIFRAUDE termina, trabalho jogado fora
[300 ms] BANDEIRA termina, trabalho jogado fora
[300 ms] só agora o get() lança

Deu 600 conexão·ms consumidos para produzir uma negativa que já era certa aos 50ms. E o motivo não é o get() ser lento, é que ele bloqueia na ordem em que você escreveu e não na ordem em que as coisas acontecem, mas indo mais fundo o problema real é que o pool é um saco de tarefas anônimas, quando você faz submit aquilo vira um Runnable numa fila e o pool não sabe que as três tarefas são irmãs, não sabe que uma depende da outra fazer sentido, não existe a informação de parentesco em lugar nenhum, então não existe ninguém para avisar ninguém.

E sob carga isso não degrada de forma linear, porque quando as conexões acabam as autorizações começam a enfileirar, a latência sobe, o adquirente faz retry, o que gera mais carga ainda, e um serviço degradado acaba derrubando o autorizador inteiro não por causa dele mas porque você continuou pagando pedágio por trabalho que já estava perdido. Em pagamento isso tem um agravante que eu acho pouco discutido, porque cada chamada que você deixa correr depois da decisão já tomada é uma chamada que pode ter efeito do outro lado, e aí você entra no território de idempotência e reversão.

O que a StructuredTaskScope adiciona

É exatamente esse parentesco que a StructuredTaskScope traz, e sinceramente é só isso que ela traz, o resto é consequência:

try (var scope = StructuredTaskScope.open(
        Joiner.<Object>allSuccessfulOrThrow(),
        cfg -> cfg.withTimeout(Duration.ofSeconds(2)))) {

    var fraude    = scope.fork(() -> antifraude(transacao));
    var limite    = scope.fork(() -> limite(conta));
    var portador  = scope.fork(() -> bandeira(transacao));

    scope.join();
    return new Autorizacao(fraude.get(), limite.get(), portador.get());
}

O escopo guarda a lista das subtarefas, e quando uma delas termina ele consulta a política, se falhou ele interrompe as irmãs na própria thread que acabou de falhar, no instante da falha, sem polling e sem espera. E o fechamento de chave faz o close(), que manda o cancelamento e ainda espera todas encerrarem de fato antes de deixar você sair do bloco. Aquele withTimeout de 2 segundos também é do conjunto inteiro e não de cada chamada, que é o que você quer quando existe uma janela de autorização a respeitar.

A analogia que me fez entender de vez foi pensar que concorrência com pool é goto, você lança a tarefa e ela some, a estrutura do código deixa de corresponder à estrutura da execução. O try-with-resources já tinha resolvido isso para recursos, amarrando o tempo de vida ao escopo léxico, e a structured concurrency faz a mesma coisa com threads. O teste que eu passei a aplicar é perguntar quando aquela thread morre, e com pool a resposta honesta é que eu não sei, tenho que ler o código todo e rezar, enquanto com escopo eu aponto com o dedo para o fechamento de chave.

O que ela não faz, que é onde eu mais aprendi

Aqui está a parte que mudou como eu penso o assunto, porque cancelar uma tarefa não significa parar a thread. ninguem mata thread, em linguagem nenhuma.

O Thread.stop() existiu, foi depreciado em 1998 e desativado de vez no Java 20, e o motivo é bem fundamental, porque uma exceção assíncrona pode nascer entre duas instruções quaisquer:

contaOrigem.saldo -= 100;
     // morreu aqui
contaDestino.saldo += 100;

Cem reais deixaram de existir e nenhum código consegue se proteger disso, porque toda linha que você escreve assume que a próxima vai rodar, e essa é a suposição mais básica que existe na programação. Não é limitação do Java, o Go tem context.Context, o C# tem CancellationToken, e todos são cooperativos.

O que existe de verdade é o interrupt(), que liga um booleano e dá um empurrão em quem está dormindo, ou seja é um bilhete deixado na mesa. Quem está esperando IO acorda, lê o bilhete e se mata sozinho lançando a InterruptedException, e quem está num laço de CPU sem checar nada simplesmente ignora e roda para sempre.

E aí mora a pegadinha que me pegou. Esse código aqui parece virtuoso:

for (int tentativa = 1; tentativa <= 3; tentativa++) {
    try {
        return consultarBandeira(transacao);
    } catch (Exception e) {          // InterruptedException também é uma Exception
        log.warn("falhou, tentando de novo");
    }
}

É retry, todo mundo faz, e em integração com bandeira ou adquirente é praticamente obrigatório, ninguém olha isso e vê bug. Só que a JVM limpa a flag antes de lançar a InterruptedException, então a tentativa número 2 começa com a thread limpa, abre uma conexão nova e trabalha o tempo inteiro, porque não sobrou nenhum vestígio de que alguém pediu cancelamento. O sinal foi destruído dentro do catch.

Medi isso mantendo a coordenação idêntica e trocando só o serviço:

[ 55 ms] LIMITE falha, cancelamento disparado
[ 57 ms] MÉTODO SAIU em 56 ms, do meu lado tudo parecia certo
[ 59 ms] BANDEIRA engoliu InterruptedException, vai tentar de novo
[ 60 ms] ANTIFRAUDE engoliu InterruptedException, vai tentar de novo
[309 ms] conexão BANDEIRA-retry#2 devolvida (250 ms)
[361 ms] conexão ANTIFRAUDE-retry#2 devolvida (301 ms)

Foram 708 conexão·ms contra 243, e repare que o método retornou aos 56ms com toda a aparência de sucesso, sem log de erro, sem exceção, sem métrica nenhuma. Você só vai descobrir isso quando o pool esgotar sob carga, e vai passar o dia procurando no lugar errado.

Com o escopo, esse mesmo bug faz o método travar até os 366ms. Parece pior, e é justamente esse o ponto. O bug não sumiu, nada faz um catch mal escrito desaparecer, mas ele deixou de ser uma thread fantasma que ninguém enxerga e virou uma latência com endereço, dentro de um bloco que eu consigo apontar, num thread dump que mostra a árvore de pai e filho. A StructuredTaskScope não te dá poder de matar nada, ela te dá detecção.

Onde isso me deixou

A regra que ficou pra mim é que quando você captura uma InterruptedException você tomou posse do único pedido de cancelamento que existia no sistema inteiro, então ou você age ou você devolve com Thread.currentThread().interrupt(), e um catch vazio não é ignorar, é destruir.

E vale uma ressalva, a structured concurrency ainda é preview, está no sexto no Java 26 com finalização esperada pro 27, e ela não substitui nada da defesa em camadas que já existia, timeout no recurso com setQueryTimeout e timeout de HTTP, bulkhead separando o pool de cada parceiro, circuit breaker, propagação de deadline. Se o seu autorizador esgota conexão em produção a primeira pergunta certa não é se você usou escopo, é se tem timeout no recurso.

e obrigado por quem leu até aqui.

Cell-Based Architecture: o por que estamos sempre tentando mitigar riscos e falhas

João Antônio — Tue, 28 Apr 2026 01:21:56 +0000

Escalar microserviços horizontalmente resolve capacidade. Mas não resolve isolamento, e essa diferença importa mais do que parece.

Cell-Based Architecture é um padrão que ainda é pouco discutido
na comunidade, mas que empresas como AWS, Slack já usam
há anos para garantir que uma falha nunca afete todos os usuários ao mesmo tempo.

A ideia é simples: em vez de escalar instâncias de um mesmo sistema, você replica a stack inteira em unidades independentes chamadas cells, onde cada uma serve um subconjunto da sua base de usuários.

O problema com microserviços tradicionais

Quando escalamos microserviços horizontalmente, normalmente fazemos isso:

O design parece resiliente. Mas na prática, um único ponto de
pressão afeta todos os usuários ao mesmo tempo:

Um bug em deployment? Todo mundo cai.
Um cliente com tráfego absurdo? Degrada a experiência de todos os outros, o famoso noisy neighbor.
Uma falha em cascata? Propaga pelo sistema inteiro.

Escala horizontal resolve capacidade. Não resolve isolamento.

E essa diferença importa muito mais do que parece.

O que é uma Cell

Uma cell é uma unidade autônoma que contém tudo que precisa
para servir um subconjunto de usuários. Aplicação, infraestrutura
e banco de dados juntos, completamente isolados das outras cells.

Cada cell é funcionalmente idêntica às outras. A diferença é que

cada uma serve um pedaço diferente da base de usuários e não sabe
que as outras existem.

As quatro propriedades que importam

### 1. Blast Radius Containment

Se a Cell 2 falha, apenas os usuários entre 1M e 2M são afetados.

Os outros continuam operando normalmente. O raio da explosão é
previsível e limitado antes mesmo do incidente acontecer.

### 2. Noisy Neighbor Isolation

Um cliente corporativo com milhões de requests por dia não consegue
degradar a experiência de outros clientes que estão em cells separadas.
Cada um vive no seu próprio ambiente.

### 3. Canary deployment natural

Você faz deploy na Cell 1, monitora por 30 minutos e só então

propaga para as demais. Sem feature flags complexos. O rollback
é cirúrgico e afeta só quem precisa.

### 4. Compliance e isolamento por região

Precisa garantir que dados de clientes europeus fiquem na Europa?

Cells por região resolvem isso de forma estrutural, não como
um patch em cima de outro patch.

Como o roteamento funciona

O Cell Router é o único componente verdadeiramente global.
Ele resolve para qual cell cada request deve ir:

Request chega
|
Cell Router consulta: qual cell serve esse tenant_id?

|

Encaminha para Cell N

O mapeamento de tenant_id para cell_id fica em um store leve
e altamente disponível. Redis ou DynamoDB funcionam bem aqui ou outro que queira.

## "Mas isso não é só sharding?"

Não exatamente, e essa é a confusão mais comum.

Sharding é uma estratégia de banco de dados. Você distribui
os dados entre múltiplos nós, mas a aplicação continua sendo uma só.

Mas nem tudo nesse modelo representa o melhor dos mundos. Existem partes difíceis nessas decisões arquiteturais.

Por exemplo, caso seja necessário agregar dados de todas as cells, será preciso consultar e processar informações distribuídas em múltiplos bancos. Isso pode aumentar a complexidade das consultas, dos pipelines de dados e da consistência das informações.

Outro ponto importante é a sobrecarga de uma cell específica. Se uma cell começar a receber mais tráfego do que o esperado, migrar usuários ou aumentar sua capacidade sem downtime pode ser bem mais complicado. Como os bancos são separados, a redistribuição de dados exige mais cuidado, planejamento e mecanismos seguros de migração.

Além disso, qualquer mudança estrutural no banco, como alterações de schema, índices ou procedures, precisa ser aplicada em todos os N bancos existentes. Isso exige uma boa estratégia de versionamento, automação e rollout gradual.

Ou seja, apesar de ser uma solução robusta e escalável, ela também traz novos desafios operacionais. Toda decisão arquitetural resolve alguns problemas, mas inevitavelmente adiciona outros.

por quê?

João Antônio — Wed, 04 Feb 2026 10:47:10 +0000

O desenvolvimento de software exige, de certa forma, um esforço "cognitivo" mínimo da máquina. Diante disso, acredito que pontos como entendimento e compreensão profunda produzem soluções cada vez mais robustas para a grande gambiarra que é a combinação de estruturas lógicas que se transformam em instruções com um determinado fim. O comportamento de uma instrução é interpretado com um nível específico de precisão, não de significado.

Essa grande gambiarra nasce da interpretação de sinais elétricos. Enquanto elétrons percorrem circuitos em busca de uma fuga para despejar sua energia em algum ponto final, eles se tornam prisioneiros do próprio circuito. São quase escravos de portas que permitem ou bloqueiam sua passagem, velocistas que correm sem saber para onde, sem linha de chegada, queimando todo o combustível disponível até a dissipação total.

Compreender essas abstrações, assim como as interpretações existentes em cada camada de software e hardware, traz uma enorme sabedoria para a tomada de decisão. Esse entendimento nos conduz à percepção de que tudo depende de contratos fortes e de implementações feitas com o mínimo possível de brechas de sentido e de processo. Quanto mais profundo é o entendimento das camadas, menor é o espaço para ambiguidades e maior é a confiabilidade dos sistemas construídos.

JVM, Java Memory Model e CPU: por que funciona em x86 e quebra em ARM

João Antônio — Mon, 15 Dec 2025 02:17:33 +0000

“Mas nunca deu problema na minha máquina.”

Provavelmente porque sua máquina é x86. Troca pra ARM e alguns bugs de concorrência que estavam “dormindo” aparecem.

A ideia central: x86 costuma ser mais “conservador” na prática, enquanto ARM permite mais reordenações. Se seu código depende de comportamento “bonzinho” do hardware, ele pode sobreviver em x86 e falhar em ARM.

O que o Java Memory Model (JMM) realmente garante

O JMM não fala “threads compartilham memória e pronto”. Ele define:

visibilidade: quando o que uma thread escreveu passa a ser visto por outra
ordem: quais reordenações são permitidas
happens-before: a relação que cria garantias reais entre threads

Sem um happens-before entre duas ações, você não tem garantia de:

ver o valor mais recente
ver as coisas na ordem que você escreveu
ver um objeto “pronto”

Isso é o motivo de muitos bugs “fantasma”.

O erro comum: confiar na ordem do código

Você escreve:

x = 42;
ready = true;

E imagina que outra thread, ao ver ready == true, vai necessariamente ver x == 42.

O JMM permite que, sem sincronização, outra thread observe:

ready == true
x == 0

Porque:

x pode ficar em cache/registrador
as escritas podem ser reordenadas
a outra thread pode ler valores antigos

O clássico pesado: “objeto meio construído”

Esse é o bug mais traiçoeiro.

instance = new MyObject();

Isso parece uma operação, mas por baixo vira algo tipo:

alocar memória
inicializar campos (construtor)
publicar a referência (instance aponta pro objeto)

Sem sincronização, a JVM/CPU podem efetivamente permitir que a publicação (3) aconteça antes da inicialização (2) ser visível para outras threads.

Então uma segunda thread pode ver:

if (instance != null) {
    instance.doSomething();
}

E instance não é null, mas o objeto pode estar com campos ainda em estado “default” (0/null). Em padrões como double-checked locking isso já deu dor real em produção.

Onde volatile entra (e por que resolve)

Se você declara:

private static volatile MyObject instance;

Você ganha duas coisas importantes:

Visibilidade: leitura de volatile vê o valor mais recente (não “preso” em cache local).
Ordem: volatile cria barreiras que impedem certas reordenações ao redor da variável.

Regra que importa:

Uma escrita em um volatile acontece-before de qualquer leitura posterior do mesmo volatile.

Na prática: se a thread B leu instance (volatile) como não-nulo, ela passa a ter garantia de enxergar as escritas que aconteceram antes da thread A publicar essa referência (incluindo os writes do construtor que “prepararam” o objeto).

“Como funciona por baixo dos panos”

Escrita em volatile

Quando a JVM compila uma escrita em volatile, ela precisa garantir que:

todas as escritas anteriores não fiquem “penduradas” e invisíveis

a publicação do valor não “passe na frente” de coisas anteriores

Isso é implementado inserindo memory fences/barriers ao redor do acesso (o tipo exato depende da arquitetura e do JIT).

Leitura de volatile

Quando a JVM compila uma leitura de volatile, ela precisa garantir que:

você não leia um valor velho do cache/registrador
leituras seguintes não sejam movidas “pra antes” dessa leitura

Também usa barreiras e instruções com semântica apropriada.

x86 vs ARM: por que a diferença aparece

x86 (modelo mais forte na prática)

Em x86, muitas reordenações são menos agressivas e a plataforma tende a “ajudar” sem você pedir. Não significa que o código está correto — significa que o bug pode não se manifestar.

Resultado: muita gente escreve código sem happens-before e “passa”.

ARM (modelo mais fraco)

ARM permite mais reordenação e exige sincronização explícita para garantir ordem/visibilidade. Se você não usou volatile/synchronized/locks/atomics, ARM tem mais chance de mostrar o bug.

Resultado: o mesmo programa “ok” em x86 pode falhar em ARM sob carga.

Regra prática (sem filosofia)

Se tem compartilhamento entre threads, escolha uma estratégia:

volatile: bom para flags/estado simples e publicação segura de referência
synchronized/Lock: bom para invariantes e operações compostas
Atomic*: bom para operações atômicas sem lock (CAS), com custos/limites próprios

Se você não tem happens-before, você está apostando na arquitetura e no acaso.

Implementando preço baseado em volumetria com desconto retroativo

João Antônio — Sat, 08 Nov 2025 14:22:56 +0000

Vamos à ideia de trabalhar com tiers por volumetria.
Neste exemplo, defini 3 tiers, onde os valores mínimo e máximo são inclusivos, ou seja, tanto o limite mínimo quanto o limite máximo estão dentro do tier.

Se o max for 0, quer dizer que vai do min até o “infinito”.
Cada tier tem um unitPrice, que é o preço de cada pagamento naquela faixa.

No PlanVersions, a ideia é ter várias versões de um mesmo plano convivendo ao mesmo tempo.

Se rolar uma atualização de preço e você não quiser que os clientes antigos sejam impactados, o EffectiveAt entra justamente pra isso: você usa a data pra decidir qual versão do plano vale pra cada cobrança.

Já o CustomerPricing é o vínculo entre o plano e o cliente — e ali você pode colocar um desconto se o cliente for especial… ou só muito gente boa mesmo kkkkk 😄

aqui abaixo está o uso/exemplo:

keep going until you're satisfied or dead.

equals, hashcode, hashmap

João Antônio — Wed, 22 Oct 2025 01:18:13 +0000

O papel de equals() e hashCode() no Java

Esses dois métodos vêm da classe Object, a base de todas as classes em Java.

Eles determinam como o Java compara objetos e como eles são organizados em coleções baseadas em hash.

equals(Object o)

Define se dois objetos são considerados “iguais”.

Por padrão (em Object), equals() compara referências (endereço na memória).

Classes costumam sobrescrever para comparar conteúdo.

class Cpu {
    String process;
    Pessoa(String process) { this.process = process; }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true; 
        if (!(o instanceof Pessoa)) 
        Pessoa p = (Pessoa) o;
        return process.equals(p.process);
    }
}

hashCode()

Retorna um número inteiro usado pelo algoritmo de hashing de coleções como HashMap e HashSet.

Serve para descobrir rapidamente onde o objeto deve ficar (qual bucket).

Objetos “iguais” segundo equals() devem ter o mesmo hashCode(),
o contrário não é obrigatório (mesmo hash não garante igualdade).

@Override
public int hashCode() {
    return Objects.hash(nome);
}

Como o HashMap realmente usa isso

Vamos entender o fluxo interno simplificado:

Você chama map.put(chave, valor).
O Java calcula hash = chave.hashCode().
Esse hash é usado pra determinar qual “bucket” no array interno vai armazenar a entrada.
Dentro do bucket, se houver colisões (outros elementos com mesmo hash), ele compara com equals() para decidir se atualiza o valor ou adiciona outro nó.
Quando você faz map.get(chave), ele repete o processo:
- calcula o mesmo hashCode(),
- vai ao mesmo bucket,
- percorre e compara com equals() até achar a chave correspondente.

O que acontece quando a chave muda

Se você altera qualquer campo da chave depois de adicioná-la ao mapa, o hashCode() calculado na inserção não corresponde mais ao hash atual.

Resultado:

O get() procura no bucket errado, não encontra.
O remove() também falha (não acha a chave antiga).
A entrada continua existindo dentro de um bucket “órfão”.
Isso não é um “vazamento” clássico, mas é um objeto perdido logicamente — ocupa memória, mas não é acessível.

Exemplo problemático

class Product{
    String name;
    int code;

    Product(String name, int code) {
        this.name= name;
        this.code= code;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Product)) return false;
        Produto p = (Product) o;
        return code == p.code;
    }

    @Override
    public int hashCode() {
        return Objects.hash(code);
    }
}

Agora veja o uso:

Map<Produto, Double> precos = new HashMap<>();
Produto p = new Produto("Mouse", 101);
precos.put(p, 79.9);


p.codigo = 999;

// Agora o hash mudou e o mapa não encntra mais a chave
System.out.println(precos.get(p)); //  null
System.out.println(precos.size()); //  1 (ainda existe internamente)

O objeto continua dentro do mapa, mas está “preso” em um bucket diferente e inacessível.

O contrato formal (equals / hashCode contract)

A especificação do Java diz:

Se dois objetos são iguais segundo equals(), eles devem retornar o mesmo valor em hashCode().

Se dois objetos têm hashCode() diferentes, eles não podem ser iguais.

Se dois objetos têm o mesmo hashCode(), eles podem ou não ser iguais (colisão).

Portanto:

equals() → true ⇒ hashCode() igual
hashCode() igual ⇒ equals() pode ser true ou false

feito por João Antônio e caso encontre algum erro, adicione aqui um comentário ou me mande um e-mail.