Равные по equals объекты обязаны иметь равный hashCode; обратное не требуется — коллизии нормальны. Иначе HashMap и HashSet ищут в другой корзине и не находят равный объект: до вызова equals дело не доходит.
А ещё Record и Lombok @EqualsAndHashCode генерируют согласованную пару
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Как HashMap ищет ключ: вычисляет hashCode, по нему выбирает корзину, и только внутри неё сравнивает кандидатов через equals.
sottoclass Point {
final int x, y;
@Override public boolean equals(Object o) {
return o instanceof Point p && x == p.x && y == p.y;
}
// hashCode не переопределён
}
Set<Point> set = new HashSet<>();
set.add(new Point(1, 2));
set.contains(new Point(1, 2)); // скорее всего falsehashCode по умолчанию — от идентичности объекта, у двух равных точек разные хеши → разные корзины → equals не вызывается.
Контракт hashCode:
Правильно: Objects.hash(x, y) или вручную 31 * x + y; те же поля, что в equals.
Один верный вариант. Подумайте, потом откройте ответ.
Идентичность против логического равенства, контракт equals и hashCode, проблема equals с наследованием и корректная реализация.
Таблица бакетов, перемешивание хеша и индекс, превращение цепочки в дерево, ресайз и load factor, контракт ключа.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.