Равенство и хеширование

В Java «равны» — это два разных вопроса. == спрашивает про идентичность: тот же ли это объект в памяти. equals() спрашивает про содержимое: равны ли объекты по смыслу. Для примитивов == сравнивает значения напрямую, но для объектов он проверяет лишь ссылку — и потому два равных по значению String или Integer вполне могут оказаться разными экземплярами.

Хеширование — продолжение той же истории. Хеш-коллекции (HashMap, HashSet) сначала выбирают корзину по hashCode(), а внутри неё сверяют equals(). Из этого вырастает жёсткий контракт: равные объекты обязаны возвращать одинаковый хеш. Переопределить equals() и забыть hashCode() — значит потерять ключ: объект ляжет в одну корзину, а искаться будет в другой. Полная карта — в слоях ниже.

Карта темы

• == против equals() — ссылочное равенство против логического и почему для String и обёрток всегда equals().
• Контракт equals/hashCode — почему переопределять оба вместе и как равные объекты обязаны делить hashCode.

Частые ошибки и ловушки

Значение для собеседований

Тему спрашивают почти на каждом junior-интервью, но проверяют не заучивание, а модель: понимаете ли вы разницу между идентичностью и содержимым и то, как эта разница управляет хеш-коллекциями.

Что обычно проверяют:

• Чем == отличается от equals() для объектов и для примитивов.
• Что делает Object.equals() по умолчанию и зачем его переопределяют.
• Обе части контракта equals/hashCode и почему методы переопределяют вместе.
• Почему ключ теряется в HashMap, если переопределён только equals().
• Ловушку == на Integer с кешем −128..127.

Типичный неверный ответ: «== и equals() — это одно и то же, просто разный синтаксис». Это открывает разговор о том, что для объектов == сравнивает ссылки, а equals() — содержимое, и именно поэтому new String("a") == new String("a") даёт false, а .equals() — true.