Краткий ответ

HashMap использует текущие значения hashCode() и equals() ключа для поиска. Если после помещения ключа изменить состояние, влияющее на эти методы, объект может оказаться в прежней корзине, но поиск будет выполняться по новым координатам, поэтому значение не найдётся.

Запись при этом обычно не удаляется автоматически: она остаётся внутри карты, но становится практически недоступной через стандартные операции поиска.

Исторический контекст

Коллекции требуют общего контракта для сравнения элементов и эффективного выбора структуры хранения. HashMap решает задачу быстрого поиска, используя хеширование, а корректность такого поиска зависит от стабильного поведения ключа.

Контракт equals() и hashCode() позволяет коллекции предполагать, что логически равные ключи имеют одинаковый хеш. Это делает возможным поиск без последовательного просмотра всех элементов, но налагает ограничение на изменение ключей во время их нахождения в карте.

Постановка проблемы

При добавлении записи карта вычисляет хеш ключа и помещает запись в соответствующую корзину. Позднее при вызове get, containsKey или remove карта снова вычисляет хеш, но уже на основе изменённого состояния ключа.

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

Подробное решение

Ключ для HashMap должен быть неизменяемым с точки зрения полей, участвующих в equals() и hashCode(), пока он находится в карте. Это не обязательно означает, что объект должен быть полностью неизменяемым: изменение несвязанных полей безопасно для поиска.

Типичная реализация выглядит так:

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

public class Demo {
    static final class Key {
        int id;
        Key(int id) { this.id = id; }
        public boolean equals(Object o) {
            return o instanceof Key k && id == k.id;
        }
        public int hashCode() { return Integer.hashCode(id); }
    }
    public static void main(String[] args) {
        Key key = new Key(1);
        Map<Key, String> map = new HashMap<>();
        map.put(key, "данные");
        key.id = 2;
        System.out.println(map.get(key)); // null
    }
}

При put ключ с идентификатором 1 попадает в корзину, выбранную для хеша 1. После изменения идентификатора get рассчитывает хеш для 2 и ищет в другой корзине. Запись не перемещается, потому что HashMap не отслеживает изменения состояния уже сохранённых ключей.

Безопасные варианты — использовать неизменяемый ключ, создавать новый ключ вместо изменения существующего либо сначала удалить запись, затем изменить ключ и снова добавить её. Удаление перед изменением требует, чтобы старое состояние ключа ещё было доступно; если оно уже потеряно, восстановление записи может потребовать обхода карты или внешнего источника данных.

Средняя сложность put, get и remove в HashMap амортизированно составляет O(1) при хорошем распределении хешей, но это не отменяет контракт неизменяемости ключа. При большом числе коллизий производительность ухудшается, однако мутация ключа остаётся прежде всего проблемой корректности, а не сложности.

Ситуация из практики

В сервисе ключом карты был объект с идентификатором клиента и изменяемым статусом. Статус участвовал в equals() и hashCode(), поэтому после обновления статуса часть записей перестала находиться, хотя размер карты продолжал расти.

Рассматривались три варианта. Можно было вручную удалять запись до изменения статуса, но это требовало строгой дисциплины и не защищало от ошибочного порядка операций. Можно было оставить изменяемый ключ и периодически пересобирать карту, но это добавляло сложность, окна некорректного поведения и лишние затраты. Лучшим вариантом оказался неизменяемый ключ только с идентификатором клиента, а статус был перенесён в значение.

После изменения модели ключ больше не менялся во время хранения в карте. Поиск стал предсказуемым, а обновление статуса не затрагивало структуру индекса.

Что кандидаты часто упускают

Можно ли изменять значение, связанное с ключом, без риска потерять запись?

Да, изменение значения само по себе не влияет на поиск ключа. HashMap использует ключ для выбора корзины и проверки совпадения, а значение не участвует в hashCode() и equals() ключа.

Риск появляется косвенно, если значение содержит ссылку на сам ключ или влияет на данные, из которых вычисляются методы ключа. Поэтому безопасно изменять состояние значения можно только при сохранении независимости контракта ключа.

Что произойдёт, если мутация изменит equals(), но не изменит hashCode()?

Запись может остаться в той же корзине, но проверка равенства не пройдёт. В результате get, containsKey и remove всё равно способны вернуть отсутствие ключа.

Совпадение хешей является лишь необходимым предварительным условием для проверки равенства, а не доказательством равенства. Поэтому неизменность должна охватывать все поля, участвующие в обоих методах, а не только те, которые обычно влияют на хеш.

Можно ли гарантированно удалить такую запись тем же объектом после изменения ключа?

Нет. remove использует те же текущие hashCode() и equals(), поэтому он может искать запись не в той корзине либо не признать ключ равным сохранённому представителю.

Иногда удаление случайно сработает, например при особенностях реализации или если изменённое поле не влияет на контракт, но рассчитывать на это нельзя. Если ключ уже изменён, надёжнее восстановить карту из доступных записей либо использовать внешний способ идентификации, не зависящий от повреждённого ключевого состояния.