Entity Lifecycle và equals/hashCode Trong JPA

TL;DR: Entity JPA trải qua 4 trạng thái vòng đời: Transient, Managed, Detached, và Removed. JPA hỗ trợ 7 lifecycle callbacks (@PrePersist, @PostPersist, @PreUpdate...) để can thiệp vào các mốc thay đổi. Cài đặt equals/hashCode trên JPA Entity là bài toán hóc búa vì ID bị null trước khi persist và Hibernate sử dụng CGLIB proxy cho lazy load. Tuyệt đối không dùng Lombok @Data cho Entity.

Bốn trạng thái vòng đời của Entity hoạt động như thế nào?

Mọi đối tượng JPA tại một thời điểm đều nằm trong 1 trong 4 trạng thái được quản lý bởi persistence context:

Chỉ khi Entity ở trạng thái Managed, cơ chế Dirty Checking mới theo dõi thay đổi để tự động phát sinh câu lệnh SQL UPDATE.

Bảy Lifecycle Callbacks can thiệp vào vòng đời ra sao?

JPA cung cấp 7 annotation đánh dấu method void nội bộ trong entity:

@Entity
public class Project {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private Instant createdAt;
    private Instant updatedAt;

    @PrePersist
    protected void onCreate() {
        // Chay truoc INSERT khi id van con null
        this.createdAt = Instant.now();
    }

    @PreUpdate
    protected void onUpdate() {
        // Chay truoc UPDATE khi Dirty Checking phat hien thay doi
        this.updatedAt = Instant.now();
    }

    @PostPersist
    protected void afterInsert() {
        // Chay sau INSERT, id da duoc DB gan thanh cong
    }

    @PostLoad
    protected void afterLoad() {
        // Chay sau khi Hibernate load entity tu DB len bo nho
    }
}

Tại sao cài đặt equals/hashCode cho Entity lại phức tạp?

Trong Java thông thường, equals và hashCode được sinh tự động dựa trên tất cả các trường dữ liệu. Tuy nhiên, với JPA Entity, hai trở ngại lớn xuất hiện:

1. Khóa chính ID bị null trước khi lưu: Khi entity ở trạng thái Transient, id bằng null. Nếu tính hashCode theo ID, giá trị hash ban đầu sẽ là 0.
2. Hibernate CGLIB Proxy: Đối tượng tải qua lazy load là một proxy con (subclass), không phải class gốc.

Thảm họa HashSet mất dấu Entity

Hãy xem xét kịch bản sau nếu hashCode() tính theo id:

Set<Project> set = new HashSet<>();
Project project = new Project("TaskFlow"); // id = null -> hashCode = 0
set.add(project); // Luu vao Bucket 0

projectRepository.save(project); // DB sinh id = 42 -> hashCode bien thanh 42!

boolean exists = set.contains(project); // HashSet tim tai Bucket 42 -> Tra ve FALSE!

Mặc dù đối tượng vẫn nằm trong HashSet, nhưng set.contains() trả về false vì hash code đã thay đổi giữa chừng.

Triển khai equals và hashCode chuẩn mực như thế nào?

Công thức an toàn và được Hibernate khuyến nghị:

• Dùng instanceof trong equals: Tương thích với CGLIB Proxy subclass của Hibernate (thay vì so sánh getClass() == o.getClass() vốn sẽ trả về false với proxy).
• So sánh ID an toàn: Chỉ coi hai entity bằng nhau nếu cả hai đều có ID khác null và bằng nhau.
• Trả về hằng số cố định trong hashCode(): Đảm bảo bucket trong HashSet không bao giờ bị thay đổi trước và sau khi persist.

@Entity
public class Project {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Project other)) return false; // Tuong thich Hibernate Proxy
        return id != null && id.equals(other.id);
    }

    @Override
    public int hashCode() {
        return getClass().hashCode(); // Hang so co dinh cho ca class
    }
}

Lưu ý: Trả về getClass().hashCode() khiến mọi instance của Project rơi vào cùng bucket trong Set, lookup chuyển thành O(N). Nhưng trong thực tế, các bộ Set chứa entity thường có kích thước rất nhỏ (vài chục phần tử), trade-off này hoàn toàn đáng giá để bảo toàn tính toàn vẹn dữ liệu.

Vì sao không bao giờ được dùng Lombok @Data trên Entity?

Annotation @Data của Lombok là nguyên nhân hàng đầu gây ra các lỗi runtime bí ẩn trong JPA:

1. Sinh equals và hashCode trên mọi field: Vi phạm nguyên tắc bất biến của HashSet và gây kích hoạt Lazy Loading ngoài ý muốn khi truy cập field quan hệ.
2. Sinh toString() bao gồm cả quan hệ hai chiều: Khi Entity A trỏ tới B và B trỏ ngược lại A, gọi toString() sẽ gây ra ngoại lệ StackOverflowError (vòng lặp vô tận).
3. Mặc định sinh constructor không mong muốn: Thiếu no-arg constructor cần thiết cho Hibernate.

// KHUYEN CAO: Thay @Data bang cac annotation cu the
@Getter
@Setter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Entity
public class Project { ... }

Những cạm bẫy phổ biến cần tránh là gì?

1. Gọi getClass() == o.getClass() trong equals: Sẽ trả về false khi một bên là Hibernate Lazy Proxy, phá vỡ logic so sánh.
2. Gọi network I/O trong @PrePersist: Giữ connection pool quá lâu, làm cạn kiệt tài nguyên database.
3. Dựa vào ID trong hashCode: Khiến đối tượng bị biến mất khỏi Set hoặc Map sau khi gọi repository.save().

Tự kiểm tra kiến thức

Bài tiếp theo: Tổng Kết Module 04: JPA Fundamentals