[JPA] Proxy 간단 정리 (N + 1 문제)

# Proxy는 왜 필요할까?

Member를 조회할때 Team도 같이 조회해야할까? Team이 필요할때만 그때 되서 조회하면 된다

(지연로딩을 구현하기 위함)

 

# Proxy 기초

em.find() vs em.getReference()

em.find() : 데이터베이스를 통해서 실제 엔티티 객체 조회

em.getReference() : 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회

 

# Proxy 특징

• 실제 클래스를 상속 받아서 만들어짐 (실제 클래스와 모양이 같다)
• 사용자 입장에서는 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 됨 (이론상)
• 프록시 객체는 실제 객체의 참조(target)를 보관
• 프록시 객체를 호출하면 프록시 객체는 실제 객체의 메소드를 호출함
• 프록시 객체는 처음 사용할 때 한 번만 초기화
• 프록시 객체를 초기화 할 때, 프록시 객체가 실제 엔티티로 바뀌는 것은 아님, 초기화되면 프록시 객체를 통해서 실제 엔티티에 접근 가능
• 프록시 객체는 원본 엔티티를 상속받음, 따라서 타입 체크시 주의해야함 (== 대신 instance of 사용)
• 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 프록시를 초기화하는 문제 발생 (하이버네이트는 org.hibernate.LazyInitializationException을 터트림)

# 왜 즉시로딩은 쓰면 안 좋을까?

즉시 로딩을 적용하면 예상하지 못한 SQL이 발생 -> 즉시 로딩은 JPQL에서 N+1 문제를 일으킨다

* @OneToMany, @ManyToMany 는 디폴트가 지연로딩 / @ManyToOne, @OneToOne은 디폴트가 즉시로딩 (그래서 바꿔줘야함)

 

# N+1 문제란?

연관관계에서 엔티티를 조회하면 안에 들어있는 다른 엔티티를 계속 조회해서 쿼리가 많이 나가게되는 문제

( 해당 엔티티 조회쿼리 (1) + 안에 들어있는 다른 엔티티 조회(1) ) * N (이를 전부 조회) 

당연히 쿼리가 많이 나가니 성능 이슈가 생길테고, 이를 해결하기 위한 방법은 fetch join