(Редактировать: этот ответ предполагает, что вы спрашиваете в контексте хранения key -> value отображений. Если ваши данные не представляют собой соответствия отображений, например, список строк, то любой вид Map являетсяплохой способ представить его, как с точки зрения производительности, так и с точки зрения путаницы тех, кто смотрит на ваш код.)
В общем, вы можете .Если вы используете карту с неизменяемыми ключами, которые имеют приличную реализацию hashCode() (например, String, любой из автоматически упакованных примитивов), то HashMap будет в целом вполне приемлемым.
Однако,различные структуры данных существуют по определенной причине - все они предлагают разную семантику производительности (и иногда правильности), поэтому в некоторых ситуациях вы можете выбрать другие.
Например, если вы хотите, чтобы ваши записи на карте были посещеныв определенном порядке во время итерации (на основе ключей) вы можете использовать TreeMap.Если вы хотите, чтобы порядок итераций основывался на том порядке, в котором они были вставлены, используйте LinkedHashMap.Если вам нужна хорошая производительность при простом параллельном доступе (с семантикой put-if-отсутствующий), используйте ConcurrentHashMap.Если ваши ключи являются перечислениями, то EnumMap - самая эффективная реализация.Если вы хотите, чтобы ключи хранились как слабые ссылки, используйте WeakHashMap.Если вы хотите выполнить поиск на основе конкретного используемого объекта (делая его безопасным для изменяемых ключей), используйте IdentityHashMap.
Не говоря уже о том, что если вы знаете (но не можете изменить), что ваши ключиесть плохо реализованный метод hashCode(), , особенно , если он несовместим с равными, тогда HashMap может быть плохим выбором в любом случае.
И есть много других возможных функций, которые вы можете пожелатьВаша структура данных, чтобы иметь возможность, которая не покрыта, включает (но не ограничивается):
- Определенный порядок итерации, который не отсортирован по ключу или порядок вставки
- Размер-ограниченность (особенно с настраиваемым выбором того, какую запись выгнать)
- Мягкие / фантомные ссылки для клавиш
- Ленивая инициализация, когда
get() выполняется для ключа, которого там нет
и так далее.Это особенно вероятно, если ваши собственные доменные объекты имеют определенные свойства, которые конкретная реализация Map могла бы использовать для более быстрой / чистой / улучшенной производительности (что, конечно, универсальная реализация библиотеки никогда не сможет сделать).
Обращение к выражению «аппаратные средства дешево» - это правда, но время программиста и пользователя - нет.В некоторых случаях критический цикл приложения может включать в себя много поисков на карте, так что ускорение этих поисков окажет заметное влияние на производительность.Конечно, обычно это не так, но если это так, то выбор карты с более высокой производительностью для конкретной ситуации (простой пример, который приходит на ум - использование EnumMap, где это уместно) приведет к повышению производительности - что можеточень важно.
В качестве альтернативы, некоторые реализации карт просто упрощают написание окружающего кода, его легче понимать и с меньшей вероятностью скрывать ошибки.Примером здесь может быть случай с отложенной инициализацией карты (что-то вроде ComputingMap из Google Collections).В то время как вы можете написать некоторый код с семантикой lazy-init вокруг стандартного HashMap, упаковав всю эту логику в саму реализацию карты, становится легче проверять правильность - и клиентская логика намного проще.
Так что дешевое оборудование / пространство не означает, что HashMaps оптимальны для всего.На самом деле, если что-то и является контраргументом - HashMaps достаточно экономичны по сравнению с более индивидуальными альтернативами, которые вы могли бы принять.Имея много доступного дешевого пространства, можно полностью заменить пространство временем и хранить много информации, чтобы ускорить поиск.
Обратите внимание, что я интерпретировал ваш вопрос как ", почему иногда вы можете использовать другие классы Map?"а не " который другой Maps следует использовать и когда?"Если это последнее, не стесняйтесь перефразировать или задать другой вопрос, который фокусируется на этом более конкретно.