Primeiro leia a mensagem, já que heap space, metaspace, direct buffer e GC overhead limit exceeded apontam para causas bem diferentes. Rode com heap dump on out of memory para capturar o estado na falha, depois abra o dump num analisador de memória e olhe a dominator tree para ver o que retém mais. Compare dumps ao longo do tempo para separar um vazamento genuíno de um working set que simplesmente é maior que o heap.
Por que os entrevistadores perguntam isso
O entrevistador quer um método repetível e familiaridade com as ferramentas. Distinguir as variantes do erro é um sinal rápido de credibilidade, assim como conhecer os culpados de sempre: caches sem limite, thread locals em threads de pool, vazamentos de class loader em redeploy e queries que materializam uma tabela inteira. Eles também estão checando se você não vai simplesmente aumentar o heap e chamar de resolvido.
Como estruturar sua resposta
- Leia a variante específica do erro antes de teorizar.
- Capture um heap dump automaticamente na falha.
- Analise retained size e a dominator tree, não contagens rasas.
- Confirme a correção com um cache limitado ou query em streaming, depois verifique.
Exemplo de resposta
A variante importa. Java heap space significa que objetos vivos realmente enchem o heap, metaspace significa que classes estão sendo carregadas e nunca liberadas, e um erro de direct buffer aponta para NIO ou uma biblioteca nativa em vez dos meus objetos. Então eu leio isso primeiro, depois garanto que a JVM está rodando com heap dump on out of memory e um caminho num volume que sobrevive ao restart, porque chutar sem um dump desperdiça dias. Com o dump eu olho retained size em vez de shallow size, e a dominator tree normalmente nomeia o culpado em poucos minutos. O que eu de fato encontro é repetitivo: um mapa usado como cache sem despejo, um thread local setado numa thread de pool e nunca limpo, então ele vive tanto quanto o pool, ou um método de repositório retornando todas as linhas porque alguém tirou a paginação. Eu também checo os logs de garbage collection para ver se o heap estava subindo de forma constante ou dando picos em requisições específicas. A correção é limitar alguma coisa, um cache com tamanho máximo e expiração, ou fazer streaming da query, e aí eu observo o live set ao longo de uma semana para confirmar que está plano.
Vai encarar essa entrevista em breve? O GhostPilot escuta a sua chamada ao vivo, identifica a pergunta no instante em que ela é feita e coloca uma resposta estruturada na sua tela em tempo real. Teste na sua próxima entrevista simulada ou pegue um Session Pass de $29, sem assinatura, para a hora da verdade.
Veja como funcionaPerguntas de acompanhamento que você pode esperar
- Como você distingue um vazamento de um working set que só é grande demais?
- O que causa um erro de metaspace especificamente?
- Como thread locals vazam numa thread de pool?
Mais perguntas para Desenvolvedor Java
Seu entrevistador vai fazer a própria versão desta. Cole a descrição real da vaga no Question Predictor gratuito e receba as 20 perguntas que essa vaga tem mais chance de fazer, com o que cada uma está de fato sondando.
Prever minhas perguntas