Класс HashMap<K,​V>

public class HashMap<K,V>
extends AbstractMap<K,​V>
implements Map<K,​V>, Cloneable, Serializable

Реализация интерфейса Map на основе хеш-таблицы. Эта реализация предоставляет все необязательные операции с картой и допускает значения null и ключи null. (Класс HashMap примерно эквивалентен классу Hashtable, за исключением того, что он не синхронизирован и допускает null-значения.) Этот класс не гарантирует порядок карты; в частности, он не гарантирует, что порядок останется постоянным со временем.

Эта реализация обеспечивает постоянную производительность для основных операций (get и put), предполагая, что хеш-функция правильно распределяет элементы по корзинам. Итерация по коллекционным представлениям требует времени, пропорционального «емкости» экземпляра HashMap (количество корзин) плюс его размеру (количество пар ключ-значение). Поэтому очень важно не устанавливать начальную емкость слишком высокой (или коэффициент заполнения слишком низким), если важна производительность итерации.

Экземпляр HashMap имеет два параметра, влияющих на его производительность: начальная емкость и коэффициент заполнения. Емкость — это количество корзин в хеш-таблице, а начальная емкость — это просто емкость на момент создания хеш-таблицы. Коэффициент заполнения — это мера того, насколько полной может быть хеш-таблица, прежде чем ее емкость будет автоматически увеличена. Когда количество элементов в хеш-таблице превышает произведение коэффициента заполнения и текущей емкости, хеш-таблица перехешируется (то есть внутренние структуры данных перестроены) так, что хеш-таблица имеет примерно в два раза больше корзин.

Как общее правило, стандартный коэффициент заполнения (.75) предлагает хорошее соотношение между затратами времени и места. Более высокие значения уменьшают накладные расходы на место, но увеличивают стоимость поиска (отражается в большинстве операций класса HashMap, включая get и put). При установке начальной емкости необходимо учитывать ожидаемое количество элементов в карте и ее коэффициент заполнения, чтобы свести к минимуму количество операций перехеширования. Если начальная емкость больше, чем максимальное количество элементов, деленное на коэффициент заполнения, операции перехеширования никогда не произойдут.

Если в экземпляре HashMap нужно хранить много сопоставлений, создание экземпляра с достаточно большой емкостью позволит хранить сопоставления более эффективно, чем позволять ему выполнять автоматическое перехеширование по мере необходимости для увеличения таблицы. Обратите внимание, что использование многих ключей с одинаковым hashCode() — верный способ замедлить производительность любой хеш-таблицы. Для уменьшения влияния, когда ключи являются объектами типа Comparable, этот класс может использовать порядок сравнения ключей для устранения совпадений.

Обратите внимание, что эта реализация не синхронизирована. Если несколько потоков одновременно обращаются к хеш-карте и хотя бы один из потоков изменяет карту структурно, ее необходимо синхронизировать внешне. (Структурное изменение — это любая операция, которая добавляет или удаляет одно или несколько сопоставлений; простое изменение значения, связанного с ключом, который уже содержится в экземпляре, не является структурным изменением.) Это обычно делается путем синхронизации на каком-либо объекте, естественным образом encapsulating карту. Если такого объекта нет, карта должна быть «оборачена» с помощью метода Collections.synchronizedMap. Лучше всего это сделать на этапе создания, чтобы предотвратить случайный несинхронизированный доступ к карте:

Map m = Collections.synchronizedMap(new HashMap(...));

Итераторы, возвращаемые всеми методами «представления коллекций» этого класса, являются быстропроверяемыми: если карта структурно изменяется в любое время после создания итератора, каким-либо способом, кроме метода самого итератора remove, итератор выбросит исключение ConcurrentModificationException. Таким образом, при одновременном изменении итератор быстро и чисто завершает работу, а не рискует произвольным непредсказуемым поведением в неопределенное время в будущем.

Обратите внимание, что гарантии быстропроверяемого поведения итератора не предоставляются, поскольку, как правило, невозможно дать какие-либо гарантии в случае одновременного несинхронизированного изменения. Быстропроверяемые итераторы выбрасывают исключение ConcurrentModificationException с лучшим результатом. Поэтому было бы неправильно писать программу, зависящую от этого исключения для правильности: быстропроверяемое поведение итераторов должно использоваться только для обнаружения ошибок.

Этот класс является частью Java Collections Framework.