✅ 영속성 컨텍스트란

• 엔티티를 영구 저장(Persistence)하기 위해 JPA가 관리하는 메모리 상의 환경
• EntityManager를 통해 생성되고 엔티티를 영속 상태로 관리(즉, EntityManager 인스턴스가 2개라면 영속성 컨텍스트도 2개가 존재하게 됨 - 1:1 관계)
• 즉, EntityManager는 JPA에서 엔티티를 관리하는 객체(주체)이고 영속성 컨텍스트는 엔티티를 관리하기 위한 저장소
• DB와 애플리케이션의 중간 계층 역할
• 보통 트랜잭션 단위로 생성되고 소멸됨(스프링에서는 @Transactional 단위)
• 즉, EntityManager가 관리하는 엔티티 저장소이며 여기에 저장된 객체는 자동으로 변경 감지(Dirty Checking) 되고, 트랜잭션 종료 시점에 DB에 반영됨

✅ 영속성 컨택스트의 생성과 소멸

• @PersistenceContext → EntityManager 주입
  • 진짜 EntityManager가 아닌 프록시 객체 주입
  • 해당 프록시는 현재 실행 중인 트랜잭션 스레드 로컬에 맞는 실제 EntityManager를 찾아서 위임
• 트랜잭션 시작(@Transactional 진입)
  • 트랜잭션 매니저(JpaTransactionManager)가 동작하면서 새로운 EntityManager 생성
  • 내부적으로 EntityManagerFactory.createEntityManager() 호출
  • 동시에 새 영속성 컨택스트가 생성되고 스레드 로컬에 바인딩됨
• 트랜잭션 수행 중
  • 프록시 EntityManager가 스레드 로컬에서 현재 트랜잭션용 EntityManager를 찾아 사용
  • 이 EntityManager가 관리하는 영속성 컨택스트는 트랜잭션 내애서만 살아있음
• 트랜잭션 종료 시(커밋 또는 롤백)
  • flush() 자동 호출 → DB 반영
  • EntityManager.close() 호출

    • 영속성 컨택스트 내부 캐시 및 스냅샷 완전 제거

    • 단순 clear() 보다 강력한 소멸(객체 자체도 제거)

    • clear() VS close()

      메서드	동작	시점	설명
      clear()	1차 캐시만 비움 (컨텍스트는 유지)	트랜잭션 중간	대량 처리 시 메모리 정리용
      close()	컨텍스트 자체를 폐기	트랜잭션 종료	더 이상 영속성 관리 불가

✅ 1차 캐시(First-Level Cache)

• 영속성 컨텍스트 내부에 존재하는 Map(엔티티 ID, 엔티티 인스턴스) 형태의 저장소

• 따라서 같은 트랜잭션(영속성 컨택스트) 내에서 같은 엔티티 ID로 이미 조회한 엔티티는 DB를 다시 조회하지 않고 캐시(영속성 컨택스트)에서 반환됨(영속 상태 엔티티 한정)

• 1차 캐시가 중요한 이유

  기능	설명	장점
  조회 최적화	같은 엔티티를 반복 조회해도 한 번만 DB 조회	쿼리 부하 감소
  동일성 보장	같은 PK의 엔티티는 항상 동일 객체 반환	애플리케이션 로직 안정성 향상
  변경 감지 기반	트랜잭션 종료 전까지 객체 상태 추적	update 쿼리를 최소화

✅ 변경 감지(Dirty Checking)

• 1차 캐시에는 스냅샷(엔티티 최초 조회 시점 상태)도 함께 저장(key-snapshot 형태)
• 따라서 트랜잭션이 커밋될 때 현재 엔티티 상태와 스냅샷을 비교하여 변경된 부분이 있으면 UPDATE SQL을 생성하고 flush하여 DB에 반영

✅ 변경 감지로 인한 UPDATE 폭주