Senior Java Backend — Perguntas de entrevista Java backend

Como você diagnosticaria um vazamento de memória num serviço JVM de longa duração?

Primeiro confirme que é mesmo um vazamento: observe o heap depois de um GC completo por horas, já que um dente de serra que volta à baseline não é um vazamento. Depois tire um heap dump e abra no MAT, que mostra a dominator tree — os objetos que retêm mais memória e quem os referencia. As respostas mais comuns são um cache sem limite, um ThreadLocal nunca limpo numa thread de pool, ou listeners que se registram e nunca se desregistram.

Quando você escolheria Saga em vez de uma transação distribuída?

Quase sempre, porque o commit em duas fases exige que todo participante o suporte e mantém locks pela rede, o que acopla a disponibilidade de todos os serviços ao mais lento. Uma Saga encadeia transações locais com ações compensatórias, então cada serviço faz commit independentemente e uma falha dispara um desfazimento. O custo é que você precisa projetar as compensações, e existem estados em que um observador externo pode ver uma conclusão parcial.

O que o Project Loom muda na forma de escrever código concorrente?

Threads virtuais tornam o bloqueio barato: uma thread parada em IO não ocupa mais uma thread do SO, então o modelo de uma thread por requisição escala sem a parafernália reativa. A consequência prática é que cadeias de CompletableFuture e stacks reativos adotados só para evitar bloqueio perdem a razão de existir. O que não muda é que blocos synchronized podem prender uma thread virtual, e pools de threads dimensionados para threads do SO viram a abstração errada.

Como você decide entre ajustar o GC e corrigir a alocação?

Meça primeiro a taxa de alocação. Se a aplicação aloca gigabytes por segundo, nenhum ajuste de coletor vai salvar isso, e a correção está no código — churn de objetos num loop quente, boxing, cópias defensivas. O ajuste de GC é a alavanca certa quando a alocação é razoável, mas as pausas não atingem sua meta de latência, e aí a escolha costuma ser G1 com uma meta de pausa, ou ZGC quando o heap é grande o bastante para que nem o G1 dê conta.

Um time quer dividir o monolito em microsserviços. O que você pergunta antes de concordar?

Que problema isso resolve que um limite de módulo não resolve. Deploys independentes e escalonamento independente são respostas de verdade; "microsserviços são modernos" não é. Depois, se eles conseguem lidar com dados distribuídos — nada de joins entre serviços, consistência eventual, e uma Saga para tudo que antes era uma transação só. E se a operação aguenta, porque dez serviços com um único pipeline e sem tracing é pior que o monolito.

Como você mantém uma base de código Java grande atualizável entre versões LTS?

Mantenha as dependências próximas do atual continuamente, em vez de num projeto de big-bang — o custo cresce superlinearmente conforme o quanto você está atrasado. Evite reflexão sobre internals do JDK, já que é isso que quebra sob a encapsulação de módulos. Tenha uma suíte de testes na qual você confie o bastante para acreditar numa execução verde, e faça upgrade numa branch que compile contra as duas versões, para que a migração seja revisável em vez de um precipício.