Коротко: вы нарушили контракт equals/hashCode — equals переопределён (логика по полю `name`), а `hashCode` остался от `Object` (идентичный по ссылке). Это приведёт к неверному поведению в hash‑основанных коллекциях и к другим побочным эффектам.
Что именно происходит
- Контракт: если `a.equals(b)` истинно, то обязательно `a.hashCode() == b.hashCode()`. В вашем классе это не выполняется (равные по `name` объекты имеют разные identity‑hashCode).
- HashSet/HashMap и др. используют hashCode для выбора корзины (bucket). Если hashCode разный, объекты попадают в разные корзины и `equals` для них не вызывается — коллекция считает их разными.
Как это проявится (примеры поведения)
- HashSet:
- Добавили `p1 = new Person("Alice")`, потом проверяете `contains(new Person("Alice"))` — вернёт `false`.
- Можно добавить несколько объектов с одинаковым `name` — в множестве появятся «дубликаты» с точки зрения equals.
- HashMap:
- `map.put(p1, value); map.get(new Person("Alice"))` — вернёт `null`.
- Попытки удалить по равному ключу (`remove`) не найдут запись.
- Другие структуры: Hashtable, LinkedHashSet/Map, ConcurrentHashMap — все зависят от корректного hashCode.
- Производительность: если hashCode плохо согласован с equals, может увеличиться число коллизий или неправильно распределённых элементов, что ухудшит скорость операций.
Дополнительные проблемы в вашем коде
- equals написан небезопасно: `((Person)o).name.equals(name)` бросит NPE, если `o` == null или `((Person)o).name` == null, и не проверяет `instanceof`. Это отдельная ошибка, которую тоже нужно исправить.
Как исправить (рекомендации)
- Реализовать `hashCode`, используя те же поля, что и `equals`, например:
- `public int hashCode() { return name == null ? 0 : name.hashCode(); }`
- Исправить `equals` на стандартный шаблон: проверка ссылочной равенства, `instanceof`, сравнение поля(ей) с учётом `null`.
Итог: отсутствие корректного `hashCode` ломает поведение hash‑коллекций (поиск, удаление, уникальность ключей/элементов) и может привести к труднонаходимым ошибкам.