[이펙티브 자바] 아이템11: equals를 재정의하려거든 hashCode도 재정의하라

본문은 Effective Java를 읽고 간단하게 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다.

 

선결론

• equals를 재정의할 때는 hashCode도 반드시 재정의하라
  • 이때, 재정의한 hashCode는 Object의 API 문서에 기술된 일반 규약을 따라야 한다
  • 서로 다른 인스턴스라면 되도록 해시코드도 서로 다르게 구현하라 -> 해시테이블 성능향상
• 일일이 작성하는 것은 다소 귀찮다.. 프레임워크나 IDE를 잘 이용해서 작성하자!

 

나름대로 정리해봤는데.. 결국 이 챕터의 핵심은 "논리적 동치성을 맞췄다면 물리적 동일성 또한 맞춰줘라!"라고 정리할 수 있을 것 같다. 단순하게 생각해봐도 논리적으로는 동일하더라도 물리적으로 다르다면 코드 상에서 엄청난 부수효과가 있을 것이다. 예시로 등장한 HashMap이나 HashSet은 그 한 예이다. 이 글에선 책에서 소개된 hashcode를 작성하는 방법과 주의사항에 대해 간단하게 정리하고자 한다.

 

Object의 API 문서에 기술된 일반 규약

• hashCode 메서드는 호출 횟수와 관계없이 항상 동일한 값을 반환해야 한다
  • But, 애플리케이션이 다시 실행되면 이 값이 달라질 수 있다
• equals를 통해 두 객체가 논리적으로 동일함이 확인되었다면, 두 객체의 hashCode도 똑같은 값을 반환해야 한다
  
  • 즉, 논리적으로 동일하면 물리적으로 동일해야 한다는 말이다
• equals를 통해 두 객체가 논리적으로 다름이 확인되더라도, 두 객체의 hashCode도 똑같은 값을 반환할 수 있다
  • But, 다른 값을 반환해야 해시테이블의 성능이 좋아진다

 

좋은 hashCode를 작성하는 간단한 요령

조금 복잡해보이는데, 아래의 예제코드를 보면 이해가 수월할 것이다

 

STEP1. 먼저 객체의 핵심 필드 f의 해시코드 c를 구해준다

아래는 각 필드의 타입에 따라 해시코드를 구하기 위해 수행되는 작업이다

• 1) 기본 타입 필드
  • Type.hashCode(f)를 수행한다
  • 이때, Type은 기본 타입의 박싱 클래스
• 2) 참조 타입 필드
  • 참조 타입 필드이면서 동시에 클래스의 equals 메서드 내부에서 이 필드의 equals를 재귀적으로 호출한다면 똑같이 hashCode 또한 재귀적으로 호출한다(아래 코드를 보면 좀 더 이해가 잘 될 것이다)
  • 계산이 복잡하다면 표준형을 만들어 표준형의 hashCode를 호출한다
  • 필드의 값이 null이면 0을 사용한다
• 3) 배열
  • 핵심 원소 각각을 별도 필드처럼 다룬다 -> 1), 2), 3)을 알맞게 적용
  • 배열에 핵심 원소가 없다면 상수(0 추천)를 사용한다
  • 모든 원소가 핵심 원소라면 Arrays.hashCode를 사용한다

이때, STEP1에서 다음 사항을 지키며 작업을 수행한다

• 다른 필드로부터 계산해낼 수 있는 필드는 모두 무시해도 된다
• equals 비교에 사용되지 않은 필드는 '반드시' 제외해야 한다

STEP2. 이렇게 각 필드별로 구한 해시코드를 합해주는 작업을 통해 결과값(result)을 구한다

• 1) 첫 번째 필드라면 result = c
• 2) 그 외의 필드라면 result = 31 * result + c;
• 곱셈 31 * result는 필드를 곱하는 순서에 따라 result값이 크게 달라진다
  • 이는 해시코드값의 분포도를 높이고, 따라서 해시 효과를 높여준다

STEP3. 마지막으로 자가점검과 단위 테스트를 작성한다

 

다음은 IDE가 작성해주는 equals와 hashCode에 약간의 변형을 가한 예제코드이다

User클래스는 세가지 핵심필드를 지니고, 각 필드는 기본 타입, 참조 타입, 배열이다

class User {

    private int userNo = 1;
    private Pet pet = new Pet("Dog", 4);
    private int[] stats = new int[]{4, 5, 5, 4};

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof User)) return false;
        User user = (User) o;
        // 필드의 equals를 재귀적으로 호출
        return userNo == user.userNo && pet.equals(user.pet) && Arrays.equals(stats, user.stats);
    }

    @Override
    public int hashCode() {
        int result = userNo;
        // 필드의 hashCode를 재귀적으로 호출
        result = 31 * result + pet.hashCode();
        result = 31 * result + Arrays.hashCode(stats);
        return result;
    }
}


class Pet {

    private String name;
    private int age;

    public Pet(String name, int age) {
        this.name = name;
        this.age = age;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Pet pet = (Pet) o;
        return age == pet.age && Objects.equals(name, pet.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(name, age);
    }
}

 

 

그 외의 TIP

• Object.hash()를 이용하는 것도 좋은 방법이다
  • 속도는 조금 느릴 수 있지만 간단하다 -> 성능에 민감하지 않은 상황에서 사용하자 
  • 실제 IntelliJ IDE에서도 Object.hash()를 이용하여 hashCode를 오버라이딩한다
• 클래스가 불변이고 해시코드를 계산하는 비용이 크다면 캐싱하는 방식을 고려하자
  • 객체가 주로 해시의 키로 사용된다면 인스턴스가 만들어질 때부터 해시코드를 계산해둔다
  • 그렇지 않다면 지연 초기화(lazy initialization) 전략을 사용해보자(스레드 안정성을 고려하자)
• 해시코드를 계산할 때 핵심 필드를 생략하면 안된다
  • 해시코드를 구하는 속도는 빨라지지만, 해시 품질이 나빠져 해시테이블의 성능을 저하시킬 수 있다
• hashCode가 반환하는 값의 생성 규칙을 API 클라이언트에게 드러내지마라
  • 클라이언트가 해시코드 생성 규칙을 알게 되어 여기에 의존하여 코드를 작성한다면
  • 후에 내부적으로 해시코드를 구하는 과정이 개선되더라도
  • 클라이언트는 이전의 방식에 의존하므로 "개선의 이점"을 누릴 수 없다
  • 이거는 이렇게 이해했는데.. 아닐지도..?
• 길게 얘기했지만 AutoValue 프레임워크나 IntelliJ와 같은 IDE에서 제공하는 기능들로 충분하다