equals 를 재정의한 클래스라면, 반드시 hashCode 도 재정의해야 한다.
재정의 하지 않으면 어떤 문제가 발생할까?
해시 코드 규약
-
equals비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의hashCode메서드는 항상 일관된 값을 반환해야 한다. 단, 다시 실행한다면 값이 달라져도 된다. -
equals(Object)가 두 객체를 같다고 판단했다면, 두 객체의hashCode는 똑같은 값을 반환해야 한다. -
equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의hashCode가 서로 다른 값을 반환할 필요는 없다. 단, 다른 객체에 대해서는 다른 값을 반환해야 해시테이블의 성능이 좋아진다.
hashCode 재정의를 잘못한다면 두 번째 규약에 문제가 발생한다. 만약 해당 클래스의 인스턴스를 HashMap 이나 HashSet와 같은 컬렉션의 원소로 사용할 때 문제가 발생한다.
☁️ hashCode 재정의를 잘못 할 때 발생하는 문제
논리적으로 같은 객체는 같은 해시코드를 반환해야 한다는 것이 원칙이다.
해시 코드 생성 원리
해시 코드는 기본 주소값을 기반으로 생성하며, 각 객체의 주소값을 변환하여 생성한 객체의 고유한 주소값이다.
따라서 재정의하지 않는다면 equals 를 통해 같은 논리적인 객체임이 확인되어도 다른 해시코드를 반환하여 둘을 다르다고 판단하게 된다. 아래 예제를 보자.
Map<PhoneNumber, String> m = new HashMap<>();
m.put(new PhoneNumber(707, 867, 5309), "제니");
m.get(new PhoneNumber(707, 867, 5309)); //제니가 아닌 null 반환각 PhoneNumber 인스턴스의 주소값은 당연히 다르기 때문에 논리적 동치인 두 객체가 서로 다른 해시코드를 반환한다.
설사 두 인스턴스를 같은 해시 버킷에 담았더라도, HashMap 은 해시코드가 다른 엔트리끼리는 동치성 비교를 하지 않도록 최적화되어 있어서 get() 메서드는 여전히 null을 반환한다.
컬렉션에서의 두 객체 동등성 판별
컬렉션 프레임워크에서의 HashSet, HashMap, HashTable 은 다음과 같은 방법으로 두 객체의 동등성을 판별한다.
- 우선적으로 해시 코드를 비교한다.
- 그 다음 같은 해시 코드 객체에 대해
equals를 통해 동등성까지 비교한다.
따라서 애초에 해시 코드가 다르다면, Map 에서 같은 키로 간주하지 않아서 아래 예제 코드처럼 기존 데이터에 덮어씌워지는 것이 아닌, 2개가 저장이 되버리는 문제가 발생한다.
Person person1 = new Person("kim");
Person person2 = new Person(new String("kim"));
hashMap.put(person1, "1")
System.out.println(person1.equals(person2)); //true
System.out.println(person1.hashCode()); //34233425
System.out.println(person2.hashCode()); //33532516 => 해시 코드 값이 다름
System.out.println(hashMap.get(person2)); //NULL
hashMap.put(person2, "1")
System.out.println(hashMap.size()); //2(다른 객체로 간주)
class Person{
String name;
@Override
public boolean equals(Object object){
Person anotherObj = (Person) object;
return (this.name.equals(otherObj.name); // 내용이 같다면 같다고 리턴
}Q. 그렇다면 적절한 hashCode 메서드는 어떻게 작성할까?
☁️ 좋은 hashCode를 작성하기
이상적인 해시 함수라면, 주어진 다른 인스턴스들을 32비트 정수 범위에 균일하게 분배하는 것이 좋다.
-
int변수result를 선언한 후 값 c로 초기화한다. 이때 c는 해당 객체의 첫 번째 핵심 필드를 단계2.a방식으로 계산한 해시코드다. -
해당 객체의 핵심 필드
f각각에 대해 다음 작업을 수행한다.2-a. 해당 필드의 해시코드 c를 계산한다.
-
기본 타입 필드 :
Type.hashCode(f)를 수행한다. (Type : 해당 기본 타입의 박싱 클래스) -
참조 타입 필드면서 이 클래스의
equals메서드가 이 필드의equals를 재귀적으로 호출해 비교한다면, 이 필드의hashCode를 재귀적으로 호출한다. -
배열이라면, 핵심 원소 각각을 별도 필드처럼 다룬다. 이상의 규칙을 재귀적으로 적용해 각 핵심 원소의 해시코드를 계산한 다음, 단계 2.b 방식으로 갱신한다. 배열에 핵심 원소가 하나도 없다면 단순히 상수(
0)을 사용한다. 모든 원소가 핵심 원소라면Arrays.hashCode를 사용한다.
2-b) 단계 2.a에서 계산한 해시코드 c로 result를 갱신한다.
result = 31 * result + c; -
-
result를 반환한다.
참고로, 파생 필드는 제외해도 되며 equals 비교에 사용되지 않은 필드는 반드시 제외해야 한다.
🔖 2-b 단계에서 31을 곱하는 이유?
31은 홀수이면서 소수인 반면 만약 짝수를 곱하게 되면 시프트 연산과 같은 결과를 내어 정보를 잃게 될 가능성이 존재한다. 곱셈을 시프트 연산과 뺄셈으로 대체할 수 있으며 VM에서 자동으로 최적화해준다.31 * i = (i<<5)-i
해시코드 구현 방법 1
@Override public int hashCode() {
//PhoneNumber 클래스의 핵심 필드 3개만 이용
int result = Short.hashCode(areaCode);
result = 31 * result + Short.hashCode(prefix);
result = 31 * result + Short.hashCode(lineNum);
return result;
}해시코드 구현 방법 2
@Override public int hasCode(){
return Objects.hash(lineNum, prefix, areaCode);
}Objects 클래스는 임의의 개수만큼 객체를 받아 해시코드를 계산해주는 hash() 정적 메소드를 제공해준다. 하지만, 입력 인수를 담기 위한 배열 생성 + 박싱/언박싱으로 인해 속도가 느리므로 성능에 민감하지 않은 상황에서만 사용하자.
해시코드 구현 방법 3
클래스가 불변이고 해시코드를 계산하는 비용이 크다면, 새로 계산하기 보다는 캐싱하는 방식을 고려해야 한다.
인스턴스가 만들어질때 해시코드를 미리 계산해두거나, 해시의 Key 로 사용되지 않는 경우라면 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;
}☁️ 주의사항
-
성능을 높이기 위해 해시코드를 계산할 때 핵심 필드를 생략해서는 안된다.
-
hashCode가 반환하는 값의 생성 규칙을 API 사용자에게 자세히 공표하지 말아야 한다. 하지만 이미String과Integer를 포함해, 자바 라이브러리의 많은 클래스에서 hashCode 메서드가 반환하는 정확한 값을 알려주고 있다.
☁️ 예외: String의 HashCode
앞에서 따로 정의해주지 않는다면 기본적으로 해시코드는 주소값을 이용해서 만든다 했지만, String의 hashCode 생성 방법은 약간 예외적이다.
즉, 주소값이 달라도 문자열의 내용이 같으면 같은 해시 코드 값을 가진다.
아래 사진을 보면 알 수 있듯이, 문자열에서 한 글자씩 가져와서 정수값으로 변경하고, 해당 정수값들을 더한 후 아스키 값을 가져와 사용하기 때문이다.
💡 핵심 정리
equals를 재정의할 때는 hashCode도 반드시 재정의해야 한다. 재정의한 hashCode는 Object의 API 문서에 기술된 일반 규약을 따라야 하며, 서로 다른 인스턴스라면 되도록 해시코드도 서로 다르게 구현해야 한다. 구현하기가 어렵지만, 아이템 10에서 얘기한 AutoValue 프레임워크를 사용하면 자동으로 만들어준다. IDE들도 이런 기능을 일부 제공한다.
