---

🟢 Junior Level

Короткий опис для співбесіди (30 секунд)

Ключ у HashMap зобов’язаний задовольняти чотири фундаментальні архітектурні вимоги:

1. Суворе дотримання контракту equals() та hashCode(): якщо a.equals(b) == true, то обов’язково a.hashCode() == b.hashCode(). Порушення цього правила призводить до втрати елементів у мапі та виникнення дублікатів.
2. Імутабельність (Незмінність): поля об’єкта-ключа, на основі яких обчислюються hashCode() та equals(), не повинні змінюватися після додавання до колекції.
3. Детермінованість (Консистентність): повторні виклики hashCode() зобов’язані повертати одне й те саме число. Геш не повинен залежати від часу (System.currentTimeMillis()), випадкових чисел (Random) або мережевих відповідей.
4. Безпечна робота з null: виклик equals(null) зобов’язаний повертати false, не викидаючи виняток NullPointerException. Сама HashMap підтримує рівно один null-ключ (який завжди розміщується в нульовому бакеті table[0]).

---

Порівняльна таблиця застосовності типів як ключів

Тип ключа	Застосовність	Причина та архітектурне обґрунтування
String	🟢 Ідеально	Незмінний, кешує обчислений hashCode, реалізує Comparable
Integer, Long, UUID	🟢 Ідеально	Примітивні обгортки імутабельні, надшвидке обчислення гешу
Java 21 record	🟢 Ідеально	Усі компоненти final, методи генеруються компілятором
Enum	🟡 Добре (краще EnumMap)	Імутабельний, але для переліків EnumMap набагато швидший і компактніший
Масиви (byte[], int[])	🔴 Заборонено	Успадковують Object.equals/hashCode (порівнюють адреси посилань у пам’яті)
StringBuilder	🔴 Заборонено	Змінний (мутабельний), не перевизначає методи equals/hashCode
JPA Entity з авто-ID	🔴 Заборонено	Поле ID мутує з null на число після збереження в базу даних

---

Приклади на Java 21

import java.util.HashMap;
import java.util.Map;
import java.util.UUID;

public class ValidKeysDemo {

    // 1. Ідеальний ключ на базі Java 21 Record (імутабельний, equals/hashCode "з коробки"):
    public record OrderKey(UUID customerId, long orderSequence) {
        public OrderKey {
            if (customerId == null) {
                throw new IllegalArgumentException("customerId cannot be null");
            }
        }
    }

    public static void main(String[] args) {
        Map<OrderKey, String> orders = new HashMap<>();

        OrderKey key1 = new OrderKey(UUID.randomUUID(), 101L);
        orders.put(key1, "Order_Created");

        System.out.println("Статус замовлення: " + orders.get(key1)); // Order_Created
    }
}

---

🟡 Middle Level

Чому масиви (byte[], Object[]) не можна використовувати як ключі напряму

Класична пастка для розробників:

Map<byte[], String> tokens = new HashMap<>();
byte[] token1 = new byte[]{1, 2, 3};
tokens.put(token1, "UserSession");

// ❌ ПОВЕРНЕ null!
byte[] token2 = new byte[]{1, 2, 3};
System.out.println(tokens.get(token2)); // null!

Чому це відбувається:

У мові Java масиви є об’єктами, але вони не перевизначають методи equals() та hashCode()!

• token1.equals(token2) викликає стандартний метод Object.equals, виконуючи this == o (порівняння фізичних посилань у купі);
• token1.hashCode() повертає системний identityHashCode адреси масиву;
• Два окремі масиви з абсолютно ідентичним вмістом сприймаються HashMap як два повністю різні ключі.

Як виправити: обернути масив у java.nio.ByteBuffer (у якого методи equals/hashCode побайтово порівнюють вміст буфера) або створити record із явними методами Arrays.equals та Arrays.hashCode:

public record BinaryToken(byte[] bytes) {
    @Override
    public boolean equals(Object o) {
        return o instanceof BinaryToken bt && java.util.Arrays.equals(bytes, bt.bytes);
    }
    @Override
    public int hashCode() {
        return java.util.Arrays.hashCode(bytes);
    }
}

---

Перевага реалізації інтерфейсу Comparable<K>

Починаючи з Java 8, реалізація ключем інтерфейсу Comparable<K> є критичною оптимізацією продуктивності:

1. Якщо в одному бакеті накопичується $\ge 8$ елементів, список перебудовується в червоно-чорне дерево TreeNode.
2. Якщо ключ реалізує Comparable<K>, мапа використовує метод key.compareTo(nodeKey) для швидкого бінарного впорядкування гілок дерева за пару машинних інструкцій.
3. Якщо інтерфейс не реалізовано, JVM змушена запускати аварійний арбітраж tieBreakOrder(), що виконує рефлексивне порівняння назв класів та виклик нативного System.identityHashCode(), істотно сповільнюючи операції вставки та пошуку.

---

🔴 Senior Level

Атаки через витоки за часом (Timing Side-Channel Attacks)

У системах кібербезпеки (обробка API-токенів, криптографічних підписів HMAC, сесійних селекторів) використання стандартного рядкового equals() як ключа в кеші може бути вразливим до атак за часом виконання (Timing Attack).

Стандартний метод String.equals() реалізує оптимізацію раннього виходу (Short-Circuit):

// StringLatin1.equals:
for (int i = 0; i < length; i++) {
    if (value[i] != other[i]) {
        return false; // Миттєвий вихід при першому ж неспівпалому байті!
    }
}

Зловмисник, вимірюючи час відповіді сервера із субмікросекундною точністю, може посимвольно підібрати секретний рядок: що більше початкових символів вгадано, то довше триває виконання equals().

Рішення для безпеки:

Для криптографічних секретів порівняння в equals() повинно виконуватися за константний час (Constant-Time) за допомогою java.security.MessageDigest.isEqual(a, b), який завжди перевіряє абсолютно всі байти масиву незалежно від позиції неспівпадіння.

---

Альтернатива для Enum: Чому EnumMap краща за HashMap

Якщо ключами мапи є константи переліку enum, використання звичайної HashMap є архітектурно неефективним:

// ❌ Зайві накладні витрати:
Map<Priority, Task> map = new HashMap<>();

// ✅ Максимальна швидкість та нульовий оверхед:
Map<Priority, Task> map = new EnumMap<>(Priority.class);

Архітектурні переваги EnumMap:

1. Відсутність гешування та колізій: EnumMap усередині є компактним одновимірним масивом Object[] vals, розмір якого суворо фіксований кількістю констант переліку (Enum.values().length);
2. Адресація за 1 машинний такт: індекс у масиві визначається викликом enumKey.ordinal(), що повертає порядковий номер константи (0, 1, 2...);
3. Нульові витрати пам’яті: немає об’єктів Node, немає вказівників next, відсутній ризик ресайзу та деревофікації таблиці.

---

🎯 Шпаргалка для інтерв’ю

1. 30-секундний есенс (Elevator Pitch)

Ключ у HashMap зобов’язаний бути імутабельним (щоб не зламати індексацію в бакеті), суворо дотримуватися контракту equals() та hashCode() (рівні за equals об’єкти зобов’язані видавати однаковий геш) та бути детермінованим (не залежати від часу чи мережі). Реалізація інтерфейсу Comparable істотно прискорює балансування червоно-чорних дерев при виникненні колізій. Масиви використовувати як ключі не можна (вони порівнюються за посиланням), а для Enum завжди слід обирати спеціалізовану EnumMap через пряму адресацію за ordinal().

---

2. 4 каверзні питання з глибокими відповідями

Питання 1: Чому звичайний масив (byte[] або String[]) не можна використовувати як ключ HashMap напряму?

Відповідь: Масиви в Java успадковують методи equals() та hashCode() безпосередньо від java.lang.Object без перевизначення. Метод equals() порівнює лише фізичні посилання (this == obj), а hashCode() повертає системний identityHashCode. Два окремі масиви з однаковим вмістом ніколи не будуть визнані рівними. При виклику map.get(new byte[]{1,2}) мапа завжди повертатиме null. Для використання масивів їх необхідно загортати в ByteBuffer або створювати клас-обгортку з викликами Arrays.equals та Arrays.hashCode.

Питання 2: У чому полягає архітектурна перевага EnumMap перед HashMap із ключами enum?

Відповідь: EnumMap зберігає значення у простому пласкому масиві фіксованої довжини, індексованому числовим значенням ordinal() константи. У ньому повністю відсутні накладні витрати на виділення об’єктів вузлів Node, обчислення геш-функції, бітові маски та розв’язання колізій. Читання та запис зводяться до прямого доступу за індексом vals[key.ordinal()] за 1 машинний такт із максимальною локальністю даних у кеші процесора L1/L2.

Питання 3: Навіщо ключам HashMap рекомендується реалізовувати інтерфейс Comparable?

Відповідь: Якщо в одному бакеті накопичується 8 або більше елементів, зв’язний список трансформується в червоно-чорне дерево. Для впорядкування вузлів у дереві елементи потрібно порівнювати. Якщо ключ реалізує Comparable, віртуальна машина здійснює пряме порівняння методом compareTo(). Якщо ні — HashMap застосовує резервний механізм tieBreakOrder() (порівняння назв класів та нативний виклик System.identityHashCode()), що значно уповільнює пошук та додавання.

Питання 4: Чим небезпечний «важкий» метод equals() у класі-ключа?

Відповідь: У найгіршому сценарії (при виникненні колізій у бакеті) метод equals() викликається послідовно для кожного вузла ланцюжка. Якщо equals() здійснює глибоке рекурсивне порівняння розгалужених графів об’єктів або важких рядків/документів, теоретична константа складності $O(1)$ зростає до десятків мілісекунд, блокуючи потік виконання і створюючи серйозне вузьке місце для продуктивності всієї системи.

---

3. Типові помилки та Red Flags

❌ «Ключ HashMap може бути змінним, якщо змінювати лише поля типу String.»
Правильно: Мутувати будь-які поля, задіяні в розрахунку hashCode/equals, категорично заборонено.

❌ «Використання java.net.URL у ролі ключа мапи.»
Правильно: Метод URL.equals() виконує блокуючий мережевий запит до DNS для резолвінгу IP-адреси, що призводить до зависання потоків.

❌ «Використання сирих масивів як ключів без спеціальної обгортки.»
Правильно: Масиви порівнюються за посиланням, тому отримати значення за новим масивом буде неможливо.

---

4. Пов’язані питання

• Який контракт у equals() та hashCode()
• Чи можна використовувати mutable об’єкт як ключ в HashMap
• Що станеться, якщо змінити ключ після додавання в HashMap
• Чому String часто використовують як ключ в HashMap
• Що таке колізія в HashMap