Какие требования предъявляются к классу, объекты которого будут использоваться в качестве ключа в HashMap?

Класс-ключ для HashMap должен корректно реализовывать методы hashCode() и equals(). Это необходимо для правильной работы структуры данных, основанной на хэшировании.

Критерии для hashCode() и equals():

1. Контракт между equals() и hashCode():

   • Если два объекта равны по equals(), их hashCode() обязаны быть одинаковыми.
   • Обратное не обязательно: разные объекты могут иметь одинаковый хэш-код (коллизия).

2. Требования к equals(Object o):

   • Рефлексивность: x.equals(x) — всегда true.
   • Симметричность: если x.equals(y) == true, то и y.equals(x) == true.
   • Транзитивность: если x.equals(y) и y.equals(z), то x.equals(z).
   • Консистентность: многократный вызов equals() с неизменными объектами всегда возвращает одинаковый результат.
   • Сравнение с null: x.equals(null) — всегда false.

3. Требования к hashCode():

   • Консистентность: для неизменного объекта хэш-код должен быть постоянным.
   • Эффективность: минимизация коллизий для повышения производительности.

Практический пример: Класс с полями name и id в качестве составного ключа.

import java.util.Objects;

public final class PersonKey {
    private final String name;
    private final int id;

    public PersonKey(String name, int id) {
        this.name = name;
        this.id = id;
    }

    // Реализация equals, учитывающая все значимые поля
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        PersonKey personKey = (PersonKey) o;
        return id == personKey.id && Objects.equals(name, personKey.name);
    }

    // Реализация hashCode на основе тех же полей
    @Override
    public int hashCode() {
        return Objects.hash(name, id); // Стандартная утилита из Java 7+
    }
}

Важно: Если ключ является mutable-объектом, и его поля, участвующие в расчете hashCode/equals, изменяются после добавления в HashMap, элемент может стать "потерянным" (невозможность найти по этому ключу). Поэтому предпочтительны immutable ключи.