Questão de Programação — Frameworks Java — FGV 2026
Programação›Frameworks Java
Código
fg133905
Banca
FGV
Órgão
TJ-RJ
Ano
2026
Nível
Superior
Cargo
Analista Judiciário - Tecnologia da Informação - Analista de Sistemas
Uma analista de dados está implementando uma solução de persistência de dados para um novo sistema de gerenciamento de documentos utilizando JPA 2.0. Para otimizar o desempenho e evitar o problema N+1, ela precisa garantir que as entidades relacionadas sejam carregadas de forma eficiente. Para carregar as entidades via JPA 2.0 corretamente e mitigar o problema N+1 de forma eficiente, a analista deve:
Autilizar a anotação @ManyToOne sem especificar a estratégia de carregamento, permitindo que o JPA decida a melhor abordagem;
Bimplementar consultas JPQL manuais para carregar as entidades relacionadas, garantindo o controle total sobre o processo de carregamento;
Cutilizar a anotação @OneToMany com a estratégia FetchType.LAZY e utilizar JOIN FETCH nas consultas JPQL para carregar as entidades relacionadas de forma eficiente;
Dconfigurar o FetchType como EAGER em todos os relacionamentos @ManyToOne, garantindo que as entidades relacionadas sejam sempre carregadas junto com a entidade principal;
Eutilizar a anotação @LazyToOne(false) em relacionamentos @ManyToOne, a fim de carregar as entidades relacionadas apenas quando acessadas, evitando o carregamento antecipado.
Revelar gabarito e comentário▾
GabaritoC — utilizar a anotação @OneToMany com a estratégia FetchType.LAZY e utilizar JOIN FETCH nas consultas JPQL para carregar as entidades relacionadas de forma eficiente;
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”.
Mitigação do problema N+1 em JPA 2.0
Gabarito: letra C. A combinação de FetchType.LAZY em relacionamentos @OneToMany com o uso de JOIN FETCH nas consultas JPQL é a prática recomendada para evitar o problema N+1 de forma eficiente. O LAZY adia o carregamento das coleções até o acesso, enquanto o JOIN FETCH as carrega em uma única consulta quando necessário, eliminando múltiplas queries.
O problema N+1 ocorre quando uma entidade é carregada e, para cada uma de suas coleções ou associações, uma consulta adicional é disparada. Por exemplo, ao buscar uma lista de Departamento e depois acessar a lista de Funcionario de cada um, se o carregamento for LAZY sem otimização, geram-se N+1 consultas. A solução padrão em JPA é:
Usar FetchType.LAZY para não carregar dados desnecessários.
Nas consultas JPQL onde se sabe que a coleção será acessada, utilizar JOIN FETCH para trazer os dados em uma única query (via LEFT JOIN FETCH).
Estratégia
Descrição
Eficiência contra N+1
Observação
C) LAZY + JOIN FETCH
FetchType.LAZY em @OneToMany + JOIN FETCH na JPQL
✅ Alta (carrega em uma única consulta)
Prática recomendada (gabarito)
A) @ManyToOne sem especificação
Padrão EAGER
❌ Baixa (pode gerar múltiplas consultas)
Sem controle sobre queries
B) JPQL manual sem JOIN FETCH
Consultas manuais sem otimização
❌ Baixa (não garante mitigação)
Controle impreciso
D) FetchType.EAGER em todos @ManyToOne
Carregamento ansioso geral
❌ Baixa (pode agravar o problema)
Traz dados desnecessários
E) @LazyToOne(false)
Carregamento sob demanda em @ManyToOne
❌ Baixa (não resolve N+1 em coleções)
Apenas adia o carregamento
Problema N+1 em JPA: Causa (Carregamento LAZY sem otimização, Múltiplas queries por entidade); Solução correta (GABARITO C) (FetchType.LAZY em @OneToMany, JOIN FETCH na JPQL); Abordagens incorretas (@ManyToOne sem estratégia (EAGER padrão), JPQL sem JOIN FETCH, EAGER em todos @ManyToOne, @LazyToOne(false))
Alternativa A — ❌ Incorreta
A anotação @ManyToOne tem como padrão o FetchType.EAGER. Sem especificar estratégia, o carregamento será ansioso, podendo causar sobrecarga de consultas (N+1) quando muitos registros são buscados, sem oferecer controle sobre as queries geradas.
Alternativa B — ❌ Incorreta
Consultas JPQL manuais não garantem, por si só, a mitigação do N+1. Apenas com o uso explícito de JOIN FETCH ou outras técnicas (como @EntityGraph) é possível evitar múltiplas consultas. A afirmação de "garantindo o controle total" é imprecisa, pois o controle sem a técnica correta não resolve o problema.
Alternativa C — ✅ Correta ⟵ GABARITO
Essa é a abordagem consagrada: definir FetchType.LAZY em @OneToMany (e também em @ManyToMany) para carregamento sob demanda, e nas consultas JPQL que exigem a coleção, empregar JOIN FETCH para realizar um único SELECT com JOIN eficiente. Isso evita consultas adicionais e otimiza o desempenho.
Alternativa D — ❌ Incorreta
Configurar FetchType.EAGER em todos os relacionamentos @ManyToOne pode agravar o problema N+1 se cada entidade principal disparar uma consulta para sua associação, além de trazer dados desnecessários, impactando a performance. O EAGER não é recomendado como solução geral para N+1.
Alternativa E — ❌ Incorreta
@LazyToOne(false) é uma anotação proprietária do Hibernate (não faz parte da especificação JPA 2.0). Além disso, false indica que o carregamento não é lazy (ou seja, é eager), o que pode piorar o N+1. A especificação JPA já oferece FetchType.LAZY, que deve ser preferida.
Dica: Para fixar, lembre-se: lazy para coleção, join fetch para consulta que precisa dela. Assim você otimiza sem surpresas.