🟢 Junior Level

Ключ HashMap должен соблюдать несколько важных правил:

1. Переопределить equals() и hashCode() — оба метода должны работать вместе
2. Быть неизменяемым (immutable) — после создания ключ не должен меняться
3. Возвращать одинаковый hashCode при повторных вызовах — если поля не менялись

Хорошие ключи:

String key = "userId";           // Идеальный ключ
Integer id = 42;                 // Тоже отлично
record Key(String name) {}       // Java 14+ — автоматически immutable

Плохие ключи:

StringBuilder key = new StringBuilder("userId"); // Мутабельный!
List<String> listKey = new ArrayList<>();         // Можно изменить

🟡 Middle Level

Основные требования

Требование	Описание	Последствия нарушения
Контракт equals/hashCode	Если equals() = true, то hashCode() одинаковый	Потеря элементов в карте
Иммутабельность	Поля ключа не должны меняться	“Сломанный ключ”, утечка памяти
Консистентность	Повторные вызовы дают тот же результат	Непредсказуемое поведение
Качественное распределение	hashCode должен равномерно распределять ключи	Коллизии, деградация производительности

Почему String — идеальный ключ

1. Иммутабельный по дизайну
2. Кэширует свой hashCode
3. Реализует Comparable
4. Хорошее распределение hashCode

Anti-patterns

// Антипаттерн 1: hashCode зависит от времени
@Override public int hashCode() { return System.currentTimeMillis(); }

// Антипаттерн 2: hashCode зависит от случайных чисел
@Override public int hashCode() { return new Random().nextInt(); }

// Антипаттерн 3: URL как ключ (делает сетевые запросы в equals)
Map<URL, Data> map = new HashMap<>(); // Очень медленно!

Поддержка Comparable

Если ключ реализует Comparable<K>, HashMap использует compareTo() вместо tieBreakOrder() для балансировки дерева при коллизиях (Java 8+). Это быстрее, так как compareTo() работает с содержимым объекта, а tieBreakOrder() требует дополнительных вычислений через System.identityHashCode().

🔴 Senior Level

Формальные требования

Из документации Map:

The behavior of a map is not specified if the value of an object used as a key is changed in a manner that affects equals comparisons.

Контракт Consistency

Методы equals() и hashCode() должны быть консистентны:

• Не должны зависеть от внешних ресурсов (сеть, файловая система)
• Не должны использовать случайные/временные значения
• URL.equals() — классический пример нарушения: делает DNS-запрос, блокируется при сбое сети

Internal: Comparable для Treeification

При treeification бакета:

// Если key instanceof Comparable:
//   Используется compareTo() для балансировки дерева
// Если нет:
//   tieBreakOrder() через System.identityHashCode() — медленнее

Реализация Comparable существенно ускоряет балансировку дерева, так как compareTo() работает с содержимым объекта, а tieBreakOrder() требует дополнительных вычислений.

Memory Implications

• Каждая запись = объект Node (~32-48 байт) + ключ + значение
• String-литералы из String Pool — экономят память, так как одинаковые литералы ссылаются на один объект. Это НЕ относится к new String(...).
• Record-ключи — компактные, но требуют Java 14+

Edge Cases

1. null-ключ: Допускается один, всегда в table[0]. В крупных системах — антипаттерн
2. Enum как ключ: Идеальный вариант — EnumMap. Он быстрее, потому что использует массив с ordinal() как индекс — O(1) без hashCode и коллизий.
3. Массив как ключ: equals() сравнивает ссылки, не содержимое. Используйте обёртку

Security

Ключи могут быть вектором атаки:

• Hash Flooding: подбор ключей с одинаковым hashCode
• DoS через тяжёлый equals() (сравнение больших данных)
• Side-channel attacks через timing анализа equals()

Best Practices

1. Record для сложных ключей (Java 14+)
2. Final поля — минимум, что можно сделать
3. Defensive copy в конструкторе и геттерах
4. Не использовать mutable коллекции как ключи
5. Минимизировать поля в equals/hashCode — только идентификаторы

---

🎯 Шпаргалка для интервью

Обязательно знать:

• Контракт equals/hashCode: если equals = true, hashCode одинаковый
• Иммутабельность: поля ключа не должны меняться после создания
• Консистентность: повторные вызовы hashCode = тот же результат
• Качественное распределение: hashCode должен равномерно распределять ключи
• String — идеальный ключ: immutable, кэширует hashCode, реализует Comparable
• Поддержка Comparable ускоряет treeification (compareTo вместо tieBreakOrder)

Частые уточняющие вопросы:

• Почему URL плохой ключ? — equals() делает DNS-запрос, нарушает консистентность
• Можно ли массив как ключ? — нет, equals сравнивает ссылки; используйте обёртку
• Почему EnumMap быстрее HashMap? — массив с ordinal() как индекс, O(1) без hashCode
• Можно ли null как ключ? — да, один, но в крупных системах — антипаттерн

Красные флаги (НЕ говорить):

• «Можно mutable ключ если не менять его» — хрупкое решение
• «hashCode может зависеть от времени» — нет, нарушает консистентность
• «Все объекты подходят как ключ» — нет, должны соблюдать контракт

Связанные темы:

• [[7. Что такое контракт equals() и hashCode()]]
• [[12. Можно ли использовать изменяемый объект как ключ в HashMap]]
• [[15. Почему String часто используется как ключ в HashMap]]