Forem: João Antônio

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.