Java: equals и hashCode

Контракт: кто кому обязан

Картотека объясняет всё. hashCode - номер ящика, equals - сверка документов внутри ящика. Поиск идёт в два шага: сначала по хешу выбирается ящик, потом внутри него сравниваются кандидаты. Если у одинаковых по смыслу объектов номера ящиков разные, до сверки дело просто не доходит - ровно это и случилось в замере выше.

Отсюда главный инвариант: equals-равные объекты ОБЯЗАНЫ иметь одинаковый hashCode. Обратное не требуется - разные объекты с одинаковым хешем это легальная коллизия, hash-структуры к ней готовы.

// Сам equals обязан быть рефлексивным (объект равен себе), симметричным (если x равен y, то y равен x), транзитивным, стабильным между вызовами и возвращать false на null. Звучит академично, но каждое свойство ломается живым кодом - чаще всего симметричность при наследовании.

контракт

равные объекты обязаны давать равные хеши

коллизия

разные объекты с одинаковым хешем, это законно

Что ломается: исчезающие объекты

Первый случай мы уже видели: equals есть, hashCode забыт - и contains возвращает false на только что положенный объект. Без своего hashCode объект отдаёт хеш по умолчанию, привязанный к конкретному экземпляру, поэтому второй объект ищется в другом ящике.

Второй случай подлее, потому что контракт вроде бы соблюдён. Положил ключ в HashSet, потом изменил поле, участвующее в хеше. Проверил: contains для того же самого объекта вернул false, а размер множества остался единицей. Запись лежит в ящике, вычисленном по старому хешу, ищется по новому и не находится никогда. Ключи hash-структур обязаны быть неизменяемыми.

// Третий случай встречается в коде чаще всех: метод объявлен как equals(MyType) вместо equals(Object). Это перегрузка, а не переопределение - компилятор молчит, коллекции зовут версию с Object, и contains снова false. Ловится аннотацией @Override.

Set<Point> set = new HashSet<>();
set.add(new Point(1, 2));
set.contains(new Point(1, 2)); // false - hashCode не переопределён

хеш по умолчанию

привязан к экземпляру, у копии он другой

изменяемый ключ

смена поля после put теряет запись навсегда

Константный хеш: не список, а дерево - и всё равно катастрофа

Ходовое утверждение «hashCode вернул константу - HashMap стала связным списком» устарело. С Java 8 переполненный ящик превращается в красно-чёрное дерево, и это меняет цифры. Я замерил на 20 000 ключах с константным хешем.

Ключ, реализующий Comparable: 20 000 поисков за 20,3 мс. Дерево строится по compareTo и работает за логарифм. Ключ БЕЗ Comparable: те же 20 000 поисков за 1609 мс. Разница в 79 раз, потому что упорядочить такие ключи нечем и дерево вырождается.

Для сравнения: нормальный хеш даёт те же 20 000 поисков за 2,6 мс. То есть константа замедляет в 8 раз при Comparable-ключе и в 600 с лишним раз без него.

// Формулировка для собеседования: «контракт цел, поэтому компилируется и работает, но все объекты падают в один ящик; с Java 8 он превращается в дерево, а не в список, и спасает это только если ключ Comparable».

превращение в дерево

переполненный ящик HashMap с Java 8 становится деревом

Comparable

даёт дереву порядок, без него оно вырождается

Как писать правильно: record и третий брат compareTo

Ручной канон: проверка на себя, проверка на null и тип, потом сравнение значимых полей через Objects.equals, а hashCode - через Objects.hash из тех же самых полей. Выбор между getClass() и instanceof - это выбор строгости: instanceof пропускает наследников и рискует симметричностью, если наследник добавил поля.

Наследование и equals конфликтуют по своей природе, поэтому современный ответ для объектов-значений радикален: record. Он генерирует equals, hashCode и toString по компонентам, финален и неизменяем - проблема снята конструкцией языка, а не дисциплиной.

// Есть и третий брат - compareTo. В TreeMap и TreeSet равенством считается compareTo == 0, а не equals, и они расходятся чаще, чем кажется. Живой пример я проверил: у BigDecimal значения 1.0 и 1.00 не равны через equals (различается масштаб), но compareTo даёт ноль. Один и тот же список из двух таких чисел даёт HashSet размером 2 и TreeSet размером 1.

record

класс-значение со сгенерированными equals и hashCode

compareTo == 0

равенство для сортированных коллекций, не equals

Как отвечать: «Зачем переопределять hashCode вместе с equals?»

Потому что hash-структуры ищут в два шага: сначала по hashCode выбирают ящик, потом внутри него сверяют equals. Контракт требует, чтобы равные по equals объекты давали одинаковый хеш. Переопределишь только equals - одинаковые по смыслу объекты разойдутся по разным ящикам, и до сверки дело не дойдёт. Я это специально воспроизводил: кладу в HashSet точку и тут же спрашиваю contains точкой с теми же координатами, получаю false. То есть put создаст дубликат, а get не найдёт запись, которую только что положил. Поэтому пара переопределяется всегда вместе и из одних и тех же полей. Второй важный момент: поля, участвующие в хеше, не должны меняться после того, как объект стал ключом - я проверял, изменение такого поля теряет запись даже для того же самого объекта. Ну и на практике для объектов-значений я просто беру record: там equals, hashCode и toString сгенерированы по компонентам и заведомо согласованы.

Сильный ответ: объяснён механизм поиска через два шага, назван конкретный симптом поломки, добавлена проблема изменяемого ключа и дан современный практичный выход. Три уровня глубины в одном ответе.

На чём валят

• −Переопределяют equals без hashCode. HashSet не находит только что положенный объект, вопрос почти гарантирован.
• −Пишут equals(MyType) вместо equals(Object). Это перегрузка, коллекции её не зовут, спасает только @Override.
• −Кладут в HashMap изменяемый ключ и правят поле после put. Запись теряется навсегда, память при этом занята.
• −Говорят про константный хеш «станет связным списком». С Java 8 это дерево, и цифры расходятся в 79 раз: у меня 20,3 мс с Comparable-ключом против 1609 мс без него.
• −Не знают про расхождение equals и compareTo. BigDecimal 1.0 и 1.00 дают в HashSet два элемента, а в TreeSet один.