Javahard

Dlaczego `equals()` i `hashCode()` muszą spełniać kontrakt?

Tagi

#equals#hashcode#hashmap

Odpowiedź

Jeśli dwa obiekty są równe wg `equals()`, muszą mieć ten sam `hashCode()`. Kolekcje haszujące (HashMap/HashSet) na tym polegają; złamanie kontraktu powoduje „znikające” wpisy i trudne bugi.

final class User {
  private final String email;

  User(String email) {
    this.email = email;
  }

  @Override public boolean equals(Object o) {
    if (this == o) return true;
    if (!(o instanceof User)) return false;
    return email.equals(((User) o).email);
  }

  @Override public int hashCode() {
    return email.hashCode();
  }
}

Odpowiedź zaawansowana

Głębiej

Kolekcje haszujące działają w dwóch krokach: 1) `hashCode()` wybiera kubełek. 2) `equals()` znajduje właściwy klucz w kubełku.

Najważniejsze elementy kontraktu:

Jeśli `a.equals(b)` jest true, to `a.hashCode() == b.hashCode()` też musi być true.
Odwrotność nie jest wymagana (kolizje hashy są normalne).
Dla kluczy w mapach/setach wyniki powinny być stabilne w czasie.

Praktyka

Używaj niemutowalnych pól do równości (albo nie mutuj ich, gdy obiekt jest w HashMap/HashSet).
Preferuj recordy/value objecty dla stabilnej równości.

Typowe pułapki

Mutowanie pól użytych w `hashCode()` po dodaniu do HashSet (wpis „znika”).
Nadpisanie `equals()` bez `hashCode()`.
Słaby hash => dużo kolizji => spadek wydajności.

Powiązane pytania

Java

HashMap vs ConcurrentHashMap: kiedy używać którego?

#java#collections#concurrency

Java

HashMap vs LinkedHashMap — jaka jest praktyczna różnica?

#hashmap#linkedhashmap#collections

Java

HashMap vs ConcurrentHashMap — jaka jest praktyczna różnica?

#hashmap#concurrency