equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다.
👉 Object 명세
- equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다.
- equals(Object)가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다.
- equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCode가 서로 다른 값을 반환할 필요는 없다. 단, 다른 객체에 대해서는 다른 값을 반환해야 해시테이블의 성능이 좋아진다.
논리적으로 같은 객체는 같은 해시코드를 반환해야 한다.
equals는 물리적으로 다른 두 객체를 논리적으로 같다고 할 수 있다.
Object의 기본 hashCode 메서드는 이 둘이 전혀 다르다고 판단하여, 규약과 달리 서로 다른 값을 반환한다.
Map<PhoneNumber, String> m = new HashMap<>();
m.put(new PhoneNumber(707, 867, 5309), "제니");
m.get(new PhoneNumber(707, 867, 5309)); // null
hashMap은 해시코드가 다른 엔트리끼리는 동치성 비교를 시도조차 하지 않도록 최적화 되어있기 때문에 (hashCode를 재정의 하지 않은) 위 경우 논리적 동치인 두 객체가 물리적으로는 달라 서로 다른 해시코드를 반환하여 두 번째 규약을 지키지 못한다.
👉 좋은 hashCode를 작성하는 요령
- int 변수result를선언한후값c로초기화한다.이때c는해당객체의첫 번째 핵심 필드를 단계 2.a 방식으로 계산한 해시코드다(여기서 핵심 필드란 equals 비교에 사용되는 필드를 말한다. 아이템 10 참조).
- 해당객체의나머지핵심필드f 각각에대해다음작업을수행한다.
- 해당 필드의 해시코드 c를 계산한다.
- 기본 타입 필드라면, Type.hashCode(f)를 수행한다. 여기서 Type은 해당 기본 타입의 박싱 클래스다.
- 참조 타입 필드면서 이 클래스의 equals 메서드가 이 필드의 equals를 재귀적으로 호출해 비교한다면, 이 필드의 hashCode를 재귀적으로 호출한다. 계산이 더 복잡해질 것 같으면, 이 필드의 표준형(canonical representation)을 만들어 그 표준형의 hashCode를 호출한다. 필드의 값이 null이면 0을 사용한다(다른 상수도 괜찮지만 전통적으로 0을 사용한다).
- 필드가 배열이라면, 핵심 원소 각각을 별도 필드처럼 다룬다. 이상의 규칙을 재귀적으로 적용해 각 핵심 원소의 해시코드를 계산한 다음, 단계 2.b 방식으로 갱신한다. 배열에 핵심 원소가 하나도 없다면 단순히 상수(0을 추천한다)를 사용한다. 모든 원소가 핵심 원소라면 Arrays.hashCode를 사용한다.
- 단계 2.a에서 계산한 해시코드 c로 result를 갱신한다. 코드로는 다음과 같다.
- result = 31 * result + c;
- 해당 필드의 해시코드 c를 계산한다.
- result를 반환한다.
- 파생 필드는 해시코드 계산에서 제외해도 된다.
- equals 비교에 사용되지 않은 필드는 반드시 제외해야 한다.
- 성능을 높인답시고 해시코드를 계산할 때 핵심 필드를 생략해서는 안된다.
- 특히 해시의 키로 사용하는 경우 인스턴스들의 해시코드를 넓은 범위로 고르게 퍼트려주는 효과가 있는 필드를 생략하는 경우 해시테이블의 속도가 선형으로 느려질 것이다.
- hashCode가 반환하는 값의 생성 규칙을 API 사용자에게 자세히 공표하지 말자.
♦︎ 적절한 hashCode 재정의
@Override
public int hashCode() {
int result = Short.hashCode(areaCode);
result = 31 * result + Short.hashCode(prefix);
result = 31 * result + Short.hashCode(lineNum);
return result;
}
♦︎ Object.hash()를 사용한 hashCode 재정의
성능이 민감하지 않은 상황에서만 사용해라.
@Override
public int hashCode() {
return Objects.hash(lineNum, prefix, areaCode);
}
♦︎ 불변 클래스거나 주로 해시의 키로 사용되는 경우
클래스가 불변이고 해시코드를 계산하는 비용이 크다면, 매번 새로 계산하기 보다는 캐싱하는 방식을 고려해야 한다.
이 타입의 객체가 주로 해시의 키로 사용될 것 같다면 인스턴스가 만들어질 때 해시코드를 계산해둬야 한다.
해시의 키로 사용되지 않는 경우라면 hashCode가 처음 불릴 때 계산하는 지연 초기화(lazy initialization) 전략을 쓸 수 있다.
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;
}
AutoValue 프레임워크(혹은 일부 IDE)를 사용하면 equals, hasCode를 자동으로 만들어준다. ^^
반응형
'reviews > Effective JAVA' 카테고리의 다른 글
013. clone 재정의는 주의해서 진행하라 (0) | 2022.05.05 |
---|---|
012. toString을 항상 재정의하라 (0) | 2022.05.02 |
010. equals는 일반 규약을 지켜 재정의하라 (0) | 2022.04.07 |
009. try-finally보다는 try-with-resource를 사용하라 (0) | 2022.03.19 |
007. 다 쓴 객체 참조를 해제하라 (0) | 2022.03.09 |