Entity라는 것은 DB와 mapping되는 객체이다. 이 Entity는영속성 컨텍스트에서 관리 되어 진다. 여기에서는 ⭐엔티티의 생명 주기와 어떻게 생명주기를 변화시킬 수 있는지에 관해 알아볼 것이다.
Entity를 보관하고 관리하는 공간이다.

(1) 1차 캐시
영속성 컨텍스트 내부에는 Map으로 관리되는 캐시이다. 이 때, key는 @id이며 매핑한 식별자이고 value는 엔티티 인스턴스이다. 이곳에서 엔티티를 바로 불러오기 때문에 성능이 올라간다.
(2) 쓰기 지연 SQL 저장소 (트랜잭션을 지원)
엔티티를 insert하는 상황을 생각해보자. 이 때, 엔티티 메니저는 트랜잭션을 커밋하기 전까지는 DB에 저장(flush)하는 대신에 쓰기 지연 SQL 저장소에 insert SQL을 쌓아둔다. 그리고 커밋 시에 쿼리를 DB에 보낸다. 이것이 트랜잭션을 지원하는 쓰기 지연이다.
transaction.begin();
// INSERT SQL을 DB에 보내지 않고, member3까지 모두 쌓아둔다.
em.persist(member1);
em.persist(member2);
em.persist(member3);
// 커밋하는 순간 DB에 쌓여 있는 INSERT SQL을 보낸다.
transaction.commit();
(3) 플러시(flush)
영속성 컨텍스트의 변경 내용을 DB에 반영한다. (commit은 아님) 플러시는 직접 호출하는 경우, 트랜잭션 커밋 시, JPQL 쿼리 실행 시 자동 호출한다.
(4) 변경 감지
변경 감지란 SQL에 의존적이지 않도록 엔티티의 데이터 변경을 감지하고 DB에 자동으로 반영하는 기능이다. 영속성 컨텍스트에 보관할 때 스냅샷(최초의 엔티티 상태를 복사해 저장)과 이를 비교해 감지한다.
엔티티에게는 영속 상태, 비영속 상태, 준영속 상태, 삭제 상태가 있다. 밑에 엔티티의 생명주기와 더불어서 어떤 경우에 상태가 변화하고 각각이 어느 상태인지 알아보자.

| 생명주기 | 설명 |
|---|---|
| 비영속(new/transient) | 엔티티가 영속성 컨텍스트와 전혀 관계가 없는 상태 |
| 영속(managed) | 엔티티가 영속성 컨텍스트에 저장된 상태 |
| 준영속(detached) | 영속성 컨텍스트에 저장되었다가 분리된 상태 |
| 삭제(removed) | 엔티티가 삭제된 상태 |
Entity는
EntityManager에 의해서 관리된다. 그리고 Entity의 생명 주기를 바꾸는 것도 이러한 EntityManager 객체의 메소드들이다. 위의 그림에서 메소드가 있는 것을 볼 수 있는데, 이 메소드들이 Entity의 상태를 변화시켜주는 메소드이다.
persist() : 비영속성 엔티티를 영속성 엔티티로 변화시킨다.detach() : 영속성 엔티티를 준영속성 엔티티로 변화시킨다. clear() : 영속성 컨텍스트 내의 모든 엔티티가 준영속성 엔티티로 변화된다. merge() : 준영속성 엔티티를 영속성 엔티티로 변화시킨다. remove() : 엔티티를 삭제 상태로 변화시킨다. find() : DB에서 조회한다.