Проблемы в строке `public int hashCode(){ return 31*id + name.hashCode(); }`:
- NullPointerException: если `name == null`, вызов `name.hashCode()` бросит NPE.
- Несоответствие контракту equals/hashCode: если метод `equals` сравнивает другие поля (например только `id`), а `hashCode` использует ещё `name`, контракт нарушится (равные объекты должны иметь одинаковый hashCode).
- Изменчивость полей: если `id` или `name` изменяются после помещения объекта в HashMap/HashSet, хеш-таблица станет некорректной (стабильность хеша нарушена).
- Переполнение int: арифметическое переполнение допустимо и ожидаемо для хеш-функции — не ошибка сама по себе, но стоит об этом помнить.
Правильная реализация (учёт `null`, согласованность с equals, стабильность):
- Убедиться, что `equals` сравнивает те же поля, что и `hashCode`.
- Обрабатывать `null` для ссылочных полей: использовать `(name == null ? 0 : name.hashCode())`.
- Рекомендуемый шаблон (корректно для поля `int id` и `String name`):
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (!(o instanceof MyClass)) return false; // или getClass() == o.getClass() для строгой семантики
MyClass other = (MyClass) o;
return id == other.id && java.util.Objects.equals(name, other.name);
}
@Override
public int hashCode() {
int result = Integer.hashCode(id);
result = $31$ * result + (name == null ? 0 : name.hashCode());
return result;
}
Альтернативы:
- Коротко: `return java.util.Objects.hash(id, name);` — проще, но с небольшим оверхедом (автoboxing для `int`).
- Делайте поля, участвующие в equals/hashCode, неизменяемыми (final) если объекты планируется использовать в качестве ключей.
Итог: обрабатывать `null`, синхронизировать набор полей в equals и hashCode и избегать изменения этих полей после вставки в хеш-коллекции.