Questão de Programação — Frameworks Java — FGV 2025
Programação›Frameworks Java
Código
fg107890
Banca
FGV
Órgão
CPRM
Ano
2025
Nível
Superior
Cargo
Analista em Geociências - Geoprocessamento
Em uma aplicação com Hibernate, percebe-se que ao listar entidades, ocorre o problema de "N+1 selects", prejudicando a performance geral. O desenvolvedor deseja evitar esse comportamento mantendo a integridade das entidades relacionadas.A forma mais eficaz de resolver esse problema é
Aativar o cache de segundo nível para a entidade principal.
Busar @Fetch(FetchMode.JOIN) nas associações mapeadas.
Cevitar completamente o uso de relações @ManyToOne.
Dutilizar @BatchSize com FetchMode.SELECT em todas as associações.
Eaplicar CascadeType.DETACH para reduzir acoplamento.
Revelar gabarito e comentário▾
GabaritoD — utilizar @BatchSize com FetchMode.SELECT em todas as associações.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Problema N+1 no Hibernate
Gabarito: letra D. A combinação de @BatchSize com FetchMode.SELECT resolve o problema N+1 de forma eficaz, agrupando consultas em lotes e evitando múltiplas queries individuais, sem comprometer a integridade das entidades relacionadas.
O problema N+1 ocorre quando, ao listar N entidades, são geradas N+1 consultas SQL: uma para carregar as entidades principais e uma para cada associação lazy em cada entidade. A solução mais eficaz, segundo boas práticas, é utilizar @BatchSize para carregar associações em lote, mantendo o FetchMode.SELECT para evitar joins que podem gerar produtos cartesianos.
Alternativa
Descrição
Eficácia contra N+1
Efeito colateral / Observação
A
Cache de segundo nível
❌ Não resolve
Reduz consultas repetidas, mas não otimiza o padrão de lazy loading
B
@Fetch(FetchMode.JOIN)
❌ Parcial / Piora
Pode gerar produto cartesiano com múltiplas coleções
C
Evitar @ManyToOne
❌ Inviabiliza
Remove associações, solução drástica e inadequada
D
@BatchSize + FetchMode.SELECT
✅ Sim
Agrupa consultas em lotes, sem sobrecarga de joins
E
CascadeType.DETACH
❌ Não resolve
Relacionado à desanexação, não ao carregamento
Solução N+1 (Hibernate)
1Eficaz
@BatchSize + FetchMode.SELECT
2Ineficaz
Cache de segundo nível
FetchMode.JOIN (produto cartesiano)
Evitar @ManyToOne
CascadeType.DETACH
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Ativar o cache de segundo nível reduz consultas repetidas para a mesma entidade, mas não resolve o problema N+1, que é inerente ao carregamento de associações em coleções. O cache de segundo nível não otimiza o padrão de consultas gerado pelo lazy loading.
Alternativa B — ❌ Incorreta
@Fetch(FetchMode.JOIN) pode parecer uma solução imediata ao transformar todas as consultas em um único JOIN, mas isso pode gerar um produto cartesiano quando há múltiplas coleções, aumentando o volume de dados trafegados e impactando a performance. Além disso, não é a abordagem mais eficaz para o cenário geral de N+1.
Alternativa C — ❌ Incorreta
Evitar qualquer relação @ManyToOne inviabiliza o modelo de dados orientado a objetos e não resolve o problema, apenas o contorna removendo as associações. É uma solução drástica e inadequada.
Alternativa D — ✅ Correta ⟵ GABARITO
@BatchSize com FetchMode.SELECT agrupa as consultas de associações em lotes: em vez de uma consulta para cada entidade, faz uma consulta para um lote (ex.: 10 entidades). Isso reduz drasticamente o número de queries, mantendo a integridade e sem sobrecarga de joins. É a recomendação clássica da documentação do Hibernate.
Alternativa E — ❌ Incorreta
CascadeType.DETACH está relacionado à propagação da operação de desanexação das entidades, não ao carregamento de associações. Não tem efeito sobre o problema N+1.
NÃO CAIA NESSA!
A alternativa B (FetchMode.JOIN) atrai candidatos que conhecem a técnica de eager loading, mas ela pode piorar a performance com joins multiplicativos. A banca espera que você conheça a estratégia de batching, que é a mais utilizada em produção.