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

HashMap считает ключи одинаковыми по контракту equals и hashCode, а IdentityHashMap — только если это одна и та же ссылка, то есть сравнение выполняется через ==. Поэтому два разных объекта, равных по equals, могут быть двумя разными ключами в IdentityHashMap.

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

Обычные коллекции Java предназначены для работы с логическим равенством объектов: например, два объекта пользователя с одинаковым идентификатором могут рассматриваться как один ключ. Однако алгоритмы копирования графов, обхода объектных связей и некоторые инфраструктурные инструменты должны различать именно экземпляры объектов, даже если их содержимое одинаково.

Для таких задач существует IdentityHashMap. Она намеренно использует идентичность ссылок вместо общего для Map подхода на основе equals, поэтому не является полной заменой HashMap во всех сценариях.

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

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

Неверный выбор приводит к потере отдельных записей, неправильному кэшированию или нарушению топологии копируемого графа. Обратная ошибка тоже опасна: IdentityHashMap может сохранить несколько логически равных ключей, хотя прикладная задача ожидает одну запись.

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

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

IdentityHashMap применяет идентичность объекта: ключи совпадают только при key1 == key2. Поэтому переопределения equals и hashCode ключа не определяют совпадение. В реализации используется identity-хеш объекта, связанный с его ссылочной идентичностью, а не логическим содержимым.

Это влияет и на значения: операции, в которых проверяется равенство значений, также используют ссылочную идентичность. Кроме того, IdentityHashMap допускает null; для него null == null, поэтому null может выступать одним ключом.

Ожидаемая сложность основных операций остаётся близкой к O(1), но это не обещание абсолютной гарантии для любого распределения обращений. Порядок обхода не следует использовать как контракт: IdentityHashMap не предназначена для упорядоченного хранения.

Минимальный пример различия:

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

String first = new String("id");
String second = new String("id");

Map<String, Integer> logical = new HashMap<>();
Map<String, Integer> identity = new IdentityHashMap<>();
logical.put(first, 1);
identity.put(first, 1);
identity.put(second, 2);

System.out.println(logical.size());  // 1
System.out.println(identity.size()); // 2

В HashMap второй ключ заменяет значение первого, потому что строки равны по equals. В IdentityHashMap ссылки различаются, поэтому сохраняются две записи.

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

Сервис выполняет глубокое копирование графа объектов. У узлов переопределён equals по бизнес-идентификатору, но в графе могут находиться два разных экземпляра с одинаковым идентификатором. Таблица уже созданных копий должна связывать каждый исходный экземпляр с его копией и предотвращать повторный обход циклов.

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

Выбранная IdentityHashMap прямо выражает требование задачи: один исходный объект — одна запись независимо от equals. В результате циклы обрабатываются корректно, разные экземпляры не сливаются, а реализация остаётся компактной. При этом результат не передают в код, который ожидает обычную семантику Map.

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

1. Вопрос: Повлияет ли изменение полей ключа на поиск в IdentityHashMap?

Нет, если объект остаётся тем же экземпляром. Изменение полей не меняет результат ==, поэтому ключ продолжает находиться по той же ссылке. Это отличается от HashMap, где изменение состояния, участвующего в equals или hashCode, может сделать запись практически недоступной.

Однако это не означает, что объект можно бездумно удалять из памяти: пока карта хранит сильную ссылку на ключ, объект обычно остаётся достижимым. Для задач, где ключи не должны продлевать время жизни объектов, следует рассматривать другие структуры, например WeakHashMap, но у неё иная семантика.

2. Вопрос: Можно ли безоговорочно передавать IdentityHashMap методу, принимающему Map?

Нет. Типовая совместимость есть, но семантическая совместимость может отсутствовать. Код, который предполагает, что равные по equals ключи всегда представляют одну запись, может получить неожиданные дубликаты.

Особенно опасны операции сравнения карт, проверки содержимого и работа с представлениями entrySet: поведение должно интерпретироваться с учётом identity-семантики. Поэтому тип следует использовать на границе алгоритма, которому нужна идентичность, а не как универсальную реализацию Map.

3. Вопрос: Гарантирует ли IdentityHashMap порядок обхода или строгое постоянное время операций?

Нет. Она не гарантирует порядок итерации, поэтому порядок нельзя использовать для сериализации, вывода или принятия решений. Основные операции обычно имеют ожидаемую сложность O(1), но при расширении внутренней таблицы возможна более дорогая операция переразмещения, а абсолютная гарантия постоянного времени не предоставляется.

Кроме того, IdentityHashMap не предназначена для автоматической потокобезопасности. При конкурентных изменениях нужна внешняя синхронизация или другая структура, выбранная под требования к многопоточности.