JPA - 프록시(즉시로딩 VS 지연로딩)

프록시?

em.getReference()를 통해 호출 가능
그렇다면 em.find()와 다른 점은?
em.find()는 데이터베이스를 통해서 실제 엔티티 객체를 조회. 반면 em.getReference()는 조회를 곧바로 하는 것이 아닌 프록시에다가만 조회 해놔서 미뤄 놓은 상태!

• 특징
  1. 실제 클래스를 상속 받음.
  2. 사용자는 프록시에 실제 객체의 메소드를 호출하던가 바로 사용 가능
• 사용 방식
  1. Client의 em.getReference(Member.class,"id");를 호출
  2. 그러면 프록시에서 실제 Member Entity의 참조를 보관
  3. Client가 실제 Entity를 사용 요청
  4. 프록시에서 영속성 컨텍스트를 활용하여 실제 Entity를 초기화 후 요청을 실제 Entity에게 전달

     프록시 객체는 처음 사용할 때 한번만 초기화.
     초기화 할 때, 실제 엔티티로 바뀌는 것은 아니며 프록시 객체를 통해서 실제 엔티티에 접근을 하는 것!
     만일, 영속성 컨텍스트에 실제 Entity가 있다면 getReference()를 활용하여도 실제 Entity를 반환하게 됨

상황 가정

이와 같은 테이블의 연관관계가 설정 되었다고 생각하여 봅시다
의문 . Member를 조회할 때 Team도 함께 조회?

지연 로딩

@ManyToOne(fetch = FetchType.LAZY)
지연로딩이란 즉 위의 상황에서 Member조회 시, Team Entity는 프록시를 활용하여 바로 조회하는 것이 아닌 프록시를 만들어 놓는 것을 말합니다.

프록시를 설명하며 말했듯이 실제 team Entity를 사용하는 시점에서 프록시는 실제 Entity를 초기화 합니다.
ex) team.getName(); 과 같은 코드를 활용한 경우

즉시 로딩

@ManyToOne(fetch = FetchType.EAGER)
즉시로딩이란 Member 조회 시, Team Entity도 바로 조회하는 상황을 말합니다.

모든 경우에 지연로딩을 사용하여야 함!!

• 즉시 로딩의 문제점
  • 예상하지 못하는 SQL이 발생. : 연관 관계에 따라 어떤 쿼리가 나갈지를 모를 수 도 있음!
  • JPQL 에서 N+1문제!!!

    즉시로딩을 사용하면 안되는 젤 중요한 이유!
    하나의 Entity를 조회하기 위해 날린 JPQL이 N개의 JPQL을 초래하게 되므로 N+1문제라고 합니다.
    위의 상황에 놓여있는 연관관계에서 Member와 Team 은 N:1 매핑 관계 상태입니다.
    여기서 Member객체를 조회할 때 즉시로딩을 사용한다고 생각하여 봅시다!
    Team 객체를 바로 조회를할 것 입니다.
    즉, Member Entity만 조회하기 위하여 SELECT문을 날렸는데 관련되어 있는 Team Entity를 모두 조회하기위해 관련되어 있는 Team Entity에 대하여 SELECT문을 다 날리는 상황을 초래합니다. 이는 성능 저하를 이끌게 되죠!

• @ManyToOne, @OneToOne은 기본이 즉시 로딩이므로 LAZY설정을 따로 해줘야 합니다!
• 그럼 지연로딩으로만 해결이 되는 건가??
  지연 로딩을 설정해 준다음 즉시로딩을 일단 막아줘야 합니다. 그 다음으로
  1. JPQL 의 fetch join 기법을 활용하여 해결
  JPQL의 fetch join은 한방 쿼리를 활용해 연관관계에 있는 Entity를 하나의 쿼리를 활용하여 조회할 수 습니다!! 나중에 따로 포스팅 하겠습니다.
  2. Batch Size를 활용하여 해결
  where 절의 in절의 크기를 크게하여 한번에 in에 많은 아이디를 집어넣어서 가져오는 방식!! 나중에 따로 포스팅 하겠습니다.
  

정리

모든 연관관계에 지연 로딩!

이상으로 포스팅을 마치겠습니다. 감사합니다 :)

이 글은 인프런 김영한님의 '자바 ORM 표준 JPA 프로그래밍 - 기본편'을 수강하고 작성합니다.
출처:https://www.inflearn.com/course/ORM-JPA-Basic