<aside> 💡

equals를 재정의한 클래스는 hashCode도 재정의 해야함!!!!

그렇지 않으면 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제가 발생

</aside>

hashCode 일반 규약

• equals 비교에 사용되는 정보가 변경되지 않았다면, hashCode 도 변하면 안됨(단, app 재실행 시 값 변경 가능)
• equals 가 두 객체가 같다고 판단했다면, 두 객체의 hashCode 는 똑같은 값을 반환 → 논리적으로 같은 객체는 같은 해시코드를 반환해야함
• equals 가 두 객체를 다르다고 판단했더라도, hashCode 는 꼭 다를 필요는 없음
  • 하지만, 다른 객체에 대해서는 다른 값을 반환해야 해시테이블 성능이 좋아짐

논리적으로 같은 객체는 같은 해시코드를 반환해야함

• equals 가 물리적으로 다른 두 객체를 논리적으로 같다고할 때, hashCode 는 서로 다른 값을 반환함

  Map<PhoneNumber, Person> map = new HashMap<>();
  map.put(new PhoneNumber(010,1234,5678), new Person("리치"));
  

  • map.get(new PhoneNumber(010,1234,5678))를 실행하면 뭘 반환할까?
    • 답
    • 왜?
  • HashMap은 해시코드가 서로 다른 엔트리끼리는 동치성 비교를 시도조차 않도록 최적화 되어있음

동치인 모든 객체에서 똑같은 hashCode 를 반환하게 한다면?

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

• 해시테이블은 O(1) 으로 동작해야하는데 O(n) 으로 느려짐
  • why? → 모든 객체에게 똑같은 값만 내어주므로 모든 객체가 해시테이블의 버킷 하나에 담겨 마치 연결리스트처럼 동작하게됌
  • Test(위와 같이하고 중간값 찾는 시나리오)
  • Result

좋은 해시 함수라면 서로 다른 인스턴스에 다른 해시코드를 반환

1. int 변수인 result를 선언한 후 값을 c로 초기화
   • 이 때, c는 해당 객체의 첫번째 핵심 필드를 단계 2.b 방식으로 계산한 해시코드
   • 여기서 핵심 필드는 equals 비교에 사용되는 필드
2. 해당 객체의 나머지 핵심 필드인 f 각각에 대해 다음 작업을 수행
   1. 해당 필드의 해시코드 c 를 계산
      • 기본 타입 필드라면, Type.hashCode(f)를 수행한다. 여기서 Type은 해당 기본타입의 박싱 클래스
      • 참조 타입 필드면서, 이 클래스의 equals 메소드가 이 필드의 equals를 재귀적으로 호출하여 비교한다면, 이 필드의 hashCode를 재귀적으로 호출
      • 필드가 배열이라면, 핵심 원소 각각을 별도 필드처럼 다룬다.모든 원소가 핵심 원소라면 Arrays.hashCode를 사용
   2. 단계 2.b에서 계산한 해시코드 c로 result를 갱신한다.
      • result = 31 * result + c;
3. result를 반환

주의할 점

• equals비교에 사용되는 필드에 대해서만 해시코드를 계산
• 성능을 높인답시고 해시코드를 계산할 때 핵심 필드를 생략해서는 안 됌
• 만약 hash로 바꾸려는 필드가 기본 타입이 아니면 해당 필드의 hashCode를 불러 구현
  • 계산이 복잡한 경우는 표준형을 만들어 구현
• 참조 타입 필드가 null일 경우 0을 사용