EqualsAndHashCode 직접 구현과 롬복의 차이

[happymink]

프로젝트 빌드 과정에서 EqualsAndHashCode 관련 2개의 경고 메세지를 확인했습니다.

1. superclass 옵션 설정 메세지

2. IDE에서의 EqualsAndHashCode 비추천 메세지

1번의 경우 EqualsAndHashCode 비교 대상을 부모 필드를 포함 할건지 안할건지 묻는 메세지로써 superclass = false 로 해결합니다.

2번의 경우 비슷한 내용이 기억나서 강의를 찾아봤는데 강의에서 @EqualsAndHashCode를 사용하지 않고 직접 구현하는 내용이 나옵니다! 하지만 저희와 다르게 강의에서는 of 옵션을 주지 않은 기본 EqualsAndHashCode와 비교를 하는데.. 저희는 of 값을 id로 줬음에도 ide가 경고를 주는 걸 보니 뭐가 맞는지 잘 모르겠습니다 ㅎㅎ...

참고 사이트 :
https://webfirewood.tistory.com/155,
https://devonce.tistory.com/55,
온라인 강의장 패캠 강의 : 10개 프로젝트로 완성하는... Part2-Ch02-03.데이터베이스 접근 로직 테스트 정의 2 (19:00~)

[Nine-JH]

말씀하신대로 적용을 해보았는데 2번에 해당하는 경고 메시지는 보이지 않네요
혹시 관련 ide 경고 전문을 찍어주실 수 있나요?

[happymink]

Using @EqualsAndHashCode for JPA entities is not recommended. It can cause severe performance and memory consumption issues. 로 나옵니다! 제 IDE 환경 설정 문제일 수도 있을까요?

[Nine-JH]

@happymink 리서치를 해보니 IntelliJ 쪽이 아니라 자사 플러그인 중 JPA Buddy 에서 발생하는 경고였네요.

우선 왜 @EqualsAndHashCode를 사용하면 문제가 되는지부터 보자면 이는 JPA의 entity에 대해 알아보셔야 하는데요. 크게 두가지가 있을 수 있겠죠?

1. 양방향 연관관계에서 치명적인 문제가 발생할 수 있다.
2. Entity Proxy의 경우에 불일치성이 발생할 수 있다.

1. 양방향 연관관계에서 치명적인 문제가 발생할 수 있다.

아마 lombok의 @ToString을 양방향 연관관계가 적용된 엔티티에서 무심코 사용하시면 겪게 될 문제인데. 연관관계 엔티티들이 서로의 toString()을 호출하게 되면서 StackOverFlow 문제를 겪게 됩니다. 그렇기 때문에 주의를 해서 비교할 적절한 파라미터 값을 선정해주어야 했습니다. @EqualsAndHashCode 역시 똑같습니다. 특정한 필드를 적용하지 않고 전체를 적용하게 된다면 서로의 equals(), hashcode()를 계속 호출하게 될 것이고 이는 StackOverFlow 문제가 또 다시 발생하게 됩니다.

2. Entity Proxy의 경우에 치명적인 문제가 발생할 수 있다.

JPA에서 Entity는 그 자체의 순수한 객체로 관리하지 않는 케이스가 있습니다. 바로 엔티티를 프록시로 관리할 경우가 있죠.
대표적인 예시가 일대다 연관관계 Collections을 Lazy Loading 할때입니다.
만약 Collection 객체가 equals()에 포함되어 있다 무심코 equals를 돌리면 어떻게 될까요? 네, 모든 Lazy 프록시 엔티티들이 모두 로드되게 됩니다.
잘못하다가는 치명적인 자원 에러가 발생할 수 있는 것이죠.

위의 문제 때문에 JPA Buddy 팀에서는 애초에 @EqualsAndHashCode와 @Data 등을 사용하지 않도록 권장하고 있어요.(@Data에는 @ToString이 들어가있죠?) 어떤 파라미터를 쓰던지 말이죠.
이를 무시하고 그냥 사용하는 개발자들이 너무 많아서... 그냥 쓰지마! 라고 하는거라고 생각하시면 좋을 것 같네요 ㅎㅎ

---

그 다음은 equals에 어떤 파리미터를 비교하면 좋을까? 라는 것인데 Id값도 주의하셔야 할 점이 있어요

ID 값은 변경될 수 있다.

해당 케이스의 가장 대표적인 예시가 바로 @GeneratedValue 입니다.
@GeneratedValue의 가장 큰 특징은 DB에게 PK값을 지정하도록 위임하는 것인데요. 그렇다면 DB에 저장하기 전에는 id가 null이라고 할 수 있겠죠?
이때의 불일치성 때문에equals(), hashCode()를 ID값만 비교하도록 설정하기 전에 많은 고민을 하시는걸 추천해요 😄
가령 프록시 객체끼리만 비교할 것이면 추천드리는 방법이지만, 실제 객체와 프록시 객체간의 비교와 같은 상황이 발생할 수 있다면 그렇게 추천하는 방법은 아닙니다~!

[Nine-JH]

결론을 말씀 안드렸네요!
결론은 of={id}를 입력하면 해당 문제를 벗어날 수 있는건 맞다! 하지만 JPA Buddy 팀에서는 해당 에너테이션 사용 자체를 권장하지 않기 때문에 계속 경고 메시지를 보내는 것이다! 그러니 쓰고싶으면 쓰고 너무 신경쓰이면... 그냥 직접 구현하자
라고 할 수 있겠네요 👍