아이템11. equals를 재정의하려거든 hashCode도 재정의하라

📍상황

• equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 함

 

이유

• hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제가 됨
• 규약

 

문제가 되는 부분

• hashCode를 잘못 재정의했을 때 문제가 되는 조항은 두 번째임
• hashCode를 재정의하지 않으면 논리적 동치인 두 객체가 서로 다른 해시코드를 반환하여 두 번째 규약을 지키지 못함 --> 즉, 논리적으로 같은 객체는 같은 해시코드를 반환해야 함

예시

Map<PhoneNumber, String> map = new HashMap<>();
map.put(new PhoneNumber(010, 1234, 5678), "java");

//PhoneNumber 클래스의 equals를 재정의했는데 hashCode를 재정의하지 않은 경우
map.get(new PhoneNumber(010, 1234, 5678)); //예상 값 : java, 실제 값 : null

• PhoneNumber 클래스의 hashCode를 재정의하지 않은 경우 논리적 동치인 두 객체가 서로 다른 해시코드를 반환하기 때문에 get 메서드는 엉뚱한 해시 버킷에 가서 객체를 찾으려 함
• 만약 두 인스턴스를 같은 버킷에 담았더라도 get 메서드는 여전히 null을 반환함
  • HashMap은 해시코드가 다른 엔트리끼리는 동치성 비교를 시도조차 하지 않도록 최적화되어 있기 때문임

 

=> 이 문제는 적절한 hashCode 메서드를 작성해주면 해결됨!

 

📍방법

올바른 hashCode 메서드는 어떤 모습이어야 할까?

 

1)

코드11-1 최악의 hashCode 구현 - 사용 금지!

@Override
public int hashCode() { return 42; }

문제점

• 모든 객체에서 똑같은 값을 반환하므로 모든 객체가 해시테이블의 동일한 버킷에 담겨 마치 연결 리스트처럼 동작함
• 평균 수행 시간이 O(1)인 해시테이블이 O(n)으로 느려짐

 

2)

• 좋은 해시 함수라면 서로 다른 인스턴스에 다른 해시코드를 반환해야 함
• 이상적인 해시 함수는 주어진 서로 다른 인스턴스들을 32비트 정수 범위에 균일하게 분배해야 함
• 이상을 완벽히 실현하기는 어렵지만 비슷하게 만드는 간단한 요령을 다음과 같음

 

해당 요령을 적용한 코드는 다음과 같음

코드 11-2 전형적인 hashCode 메서드

@Override
public int hashCode() {
    int result = Short.hashCode(areaCode);
    result = 31 * result + Short.hashCode(prefix);
    result = 31 * result + Short.hashCode(lineNum);
    return result;
}

 

추가

• 해시 충돌이 더 적은 방법을 사용해야 한다면 구아바의 com.google.common.hash.Hashing 참고

 

3)

• Objects 클래스는 임의의 개수만큼 객체를 받아 해시코드를 계산해주는 정적 메서드인 hash를 제공함
• 하지만 hash는 속도가 2) 보다 더 느림
  • 입력 인수를 담기 위한 배열이 만들어지고, 입력 중 기본 타입이 있다면 박싱과 언박싱을 거쳐야 함
  • 따라서 hash 메서드는 성능에 민감하지 않은 상황에서만 사용하자

 

코드 11-3 한 줄짜리 hashCode 메서드 - 성능이 살짝 아쉬움

@Override
public int hashCode() {
    return Objects.hash(lineNum, prefix, areaCode);
}

 

4)

• 클래스가 불변이고 해시코드를 계산하는 비용이 크다면, 매번 새로 계산하기보다는 캐싱하는 방식을 고려해야 함
• 경우에 따른 방식
  • 해당 타입의 객체가 주로 해시의 키로 사용된다면? --> 인스턴스가 만들어질 때 해시코드를 계산해둬야 함
  • 해시의 키로 사용되지 않는다면? --> hashCode가 처음 불릴 때 계산하는 지연 초기화 전략 고려해야 함
    • 필드를 지연 초기화하려면 그 클래스를 thread-safe하게 만들도록 신경써야 함 (아이템 83)

 

코드 11-4 해시코드를 지연 초기화하는 hashCode 메서드 - 스레드 안정성까지 고려해야 함

private int hashCode; //자동으로 0으로 초기화됨

@Override
public int hashCode() {
    int result = hashCode;
    if (result == 0) {
    	result = Short.hashCode(areaCode);
        result = 31 * result + Short.hashCode(prefix);
        result = 31 * result + Short.hashCode(lineNum);
        hashCode = result;
    }
    return result;
}

 

주의

1) 성능을 높이기 위해 해시코드 계산할 때 핵심 필드를 생략하면 안됨

• 해시 품질이 나빠져 해시테이블의 성능을 심각하게 떨어뜨릴 수 있음

2) hashCode가 반환하는 값의 생성 규칙을 사용자에게 자세히 공표하지 말자

• 클라이언트가 이 값에 의지하지 않게 되고, 추후에 계산 방식을 바꿀 수 있음

 

📍핵심 정리

• equals를 재정의할 때는 hashCode도 반드시 재정의해야 함
• 재정의한 hashCode는 Object의 API 문서에 기술된 일반 규약을 따라야 하며, 서로 다른 인스턴스라면 되도록 해시코드도 서로 다르게 구현해야 함
• AutoValue 프레임워크나 IDE들에서 equals와 hashCode를 자동으로 만들어주는 기능을 제공함