🟢 Junior Level

Технически — да, можно, но не рекомендуется. Если изменить поля объекта-ключа после добавления в HashMap, вы не сможете найти этот элемент.

Простая аналогия: Вы положили письмо в почтовый ящик №5. Потом перекрасили ящик в другой цвет и поменяли номер на №10. Почтальон будет искать по новому номеру и не найдёт письмо.

Пример проблемы:

public class MutableKey {
    private int id; // Не final! Можно менять

    public void setId(int id) { this.id = id; }

    @Override public int hashCode() { return id; }
    @Override public boolean equals(Object o) { /* по id */ }
}

MutableKey key = new MutableKey(1);
map.put(key, "Value"); // Попал в бакет №1
key.setId(2);          // Хеш теперь = 2
System.out.println(map.get(key)); // null! Ключ "сломан"

Решение: Используйте неизменяемые (immutable) объекты как ключи — String, Integer, Record.

🟡 Middle Level

Проблема “сломанного ключа” (Broken Key)

HashMap “запоминает” положение объекта по его hashCode() в момент put(). Если хеш меняется — элемент остаётся в старом бакете, но поиск идёт в новом.

Механизм сбоя:

1. key.hashCode() = 100 → put(key, "Value") → бакет №100
2. key.setId(2) → hashCode() = 200
3. get(key) → ищет в бакете №200 → null
4. remove(key) → тоже не найдёт → утечка памяти

Можно ли менять поля, не входящие в hashCode/equals?

Технически да, но это bad practice:

• Вводит в заблуждение других разработчиков
• Риск: в будущем эти поля могут быть добавлены в контракт

Как делать правильно

Подход	Пример
Иммутабельные классы	String, Integer, LocalDate
Record (Java 14+)	public record Key(String id) {}
Final поля	private final String id;
Delete-Update-Insert	Удалить → изменить → добавить обратно

Типичные ошибки

1. Использование Entity JPA как ключа — Entity изменяется в процессе работы
2. StringBuilder как ключ — мутабелен: его содержимое можно изменить после добавления в Map, что сломает hashCode. String гарантирует неизменяемость.
3. Коллекции как ключ — ArrayList мутабелен, используйте обёртку

🔴 Senior Level

Memory Leak Pattern

Map<MutableKey, LargeObject> cache = new HashMap<>();
// Ключи изменяются и "теряются" — не удалить, не найти
// Old Gen заполняется → Full GC → OutOfMemoryError

“Призрачные” записи занимают память, но недоступны. В высоконагруженных системах это приводит к деградации за часы/дни.

IdentityHashMap как обходной путь

Map<MutableKey, Value> map = new IdentityHashMap<>();
// Использует System.identityHashCode() и == вместо equals/hashCode
// Адрес объекта не меняется при изменении полей

⚠️ Но это меняет семантику: два разных объекта с одинаковыми полями = разные ключи. НЕ используйте IdentityHashMap, если вам нужно содержательное сравнение ключей (два разных объекта с одинаковыми полями должны считаться одним ключом). Это решение только для случаев, где важна именно идентичность ссылки.

Internal Mechanics

HashMap не отслеживает изменения ключей. Она:

• Не копирует ключ (хранит ссылку)
• Не валидирует хеш при get/put
• Полностью доверяет текущему hashCode() ключа

Edge Cases

1. Конкурентное изменение: Один поток изменил ключ, другой ищет — race condition
2. Сериализация: При десериализации создаётся новый объект — старый “призрак” остаётся
3. WeakHashMap: Если значение ссылается на ключ — циклическая зависимость, утечка

Production Diagnostics

Признаки mutable-key проблем:

• Растущий размер Map без соответствия бизнес-логике
• get() возвращает null для “точно существующих” ключей
• Итератор находит элементы, которые недоступны через get()

Best Practices для Highload

1. Всегда final поля в ключах: private final String id;
2. Records — компилятор гарантирует иммутабельность
3. Defensive copy при получении ключа в конструкторе
4. Статический анализ — запрещать mutable-ключи через code review

---

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

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

• Технически можно, но НЕ рекомендуется: изменение полей ключа = «сломанный ключ»
• HashMap запоминает бакет по hashCode() при put; при изменении — ищет в другом месте
• get() = null, remove() не найдёт → ghost entry, утечка памяти
• IdentityHashMap как обходной путь (использует == и identityHashCode), но меняет семантику
• Лучшие ключи: String, Integer, Record (immutable по дизайну)
• StringBuilder/ArrayList мутабельны — не использовать как ключи

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

• Можно ли менять поля, не входящие в hashCode? — технически да, но bad practice
• Как исправить mutable ключ? — удалить → изменить → вставить обратно, или пересоздать Map
• Почему JPA Entity плохой ключ? — Entity меняется при persist/merge
• Что такое Ghost Entry Pattern? — записи занимают память, но недоступны через get

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

• «Можно использовать mutable объект если не менять его» — хрупкое решение
• «IdentityHashMap решает все проблемы» — нет, меняет семантику на identity-based
• «HashMap отслеживает изменения ключей» — нет, не отслеживает

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

• [[13. Что случится, если изменить ключ после добавления в HashMap]]
• [[14. Какие требования к ключу HashMap]]
• [[15. Почему String часто используется как ключ в HashMap]]